Controls for editing text in Tables in R-Instat

[lilyclements]

@rdstern and I have been discussing the tables and come up with a new set of controls for the Titles tab when editing the subtitle.

@N-thony we wanted to know if the following is possible, and, if you had any additional requests or ideas for this?

We want to have a control that is similar to this:

But with the options given in the gt package in R, so instead we would have something like this:

I've numbered the different bits and go through the questions I have on this for @N-thony

1. Font - In here, we have an editable drop down giving the font to choose. Is there already a control like this in Visual Basic that we can use?
2. Size - This is the size of the font, and this can be an editable drop down that allows numerical values only. We could have in it the options that Word has: 8, 9, 10, 11, 12, 14, 16, 18, 20, 22, 24, 26, 28, 36, 48, 72
3. Bold - This could be like a button, with an arrow in the corner to select further options (like we have on our OK) to add further bold options in R (e.g., bolder, lighter). If you click the button, it makes it bold, if you unclick it, it removes that parameter and parameter. Is this possible?
4. This is a colour changer to change the colour of your font. Is it possible to have this as an option in R-Instat as a button with an arrow of the different colours?

4-5, 7-9. Are the same idea as 3., but with Italic, Underline, Sentence Case, and Alignment There are additional options if you click on the little arrow in the corner that are offered in R. No additional questions here that isn't asked in 3.!

Let me know what you think @N-thony :)

[lilyclements]

Sidenote on the R-Code Side for myself These are all in the gt::tab_style function.

1. font
2. size
3. weight, options are: "normal", "bold", "lighter", "bolder". We run "bold" if the button is pressed, "normal" if not unpressed, and "bold", "lighter", and "bolder" are options on the drop down.
4. style, options are: "normal", "italic", "oblique". We run "italic" if the button is pressed, "normal" if not unpressed, and "italic" and "italic" are options on the drop down.
5. decorate options are "overline", "line-through", or "underline". We run "underline" if the button is pressed, NULL if not unpressed, and "overline", "line-through", or "underline" are options on the drop down.
6. colour the colour of the text.
7. transform, options are "uppercase", "lowercase", or "capitalize" on the drop down.
8. align - can be one of either "center", "left", "right", or "justify" on the drop down.
9. v_align options are "middle", "top", or "bottom" on the drop down.

[lilyclements]

On reflection this might be more of a question for @Patowhiz. What are your thoughts on this @Patowhiz?

[Patowhiz]

@lilyclements this sounds like a good functionality, where will this control be placed?

[lilyclements]

@Patowhiz excellent! It will be used in the tables subdialogs multiple times; for example, the title, the subtitle, the footnotes, stub, source, table text, column names, etc.

@Patowhiz and just to add that this is the remaining exciting addition for the forthcoming R_instat. Although this is "just a tables sub-dialog" these tables are almost as exciting for tables of results, that ggplot is for graphs. For climatic it will support brilliantly formatted tables - which we have been asked about. They can even be produced as Word output in the future, so it will be excellent if we can have similar user controls here as in Word/Excel, etc.

[Patowhiz]

Then I presume the controls should be formatted/styled/arranged like the ggplot controls we have for the graph options sub dialog? @rdstern do you think consistency should matter in this case?

[lilyclements]

@Patowhiz can you explain where in the ggplot controls you are referring to? Is it like in the Title tab? I would suggest that actually we think about (in time) replacing the ggplot sub dialog with this sort of design too.

[Patowhiz]

@lilyclements yes I was referring to something like the Title tab. Notice it uses controls that are similar to other tabs like the Y-axis tab.

[lilyclements]

@Patowhiz I think if we can create something like this in the tables subdialog, then it should replace the graphics dialog controls linking to text editing too. You seem happy that this can be done? I just want to double check is it possible that we can have it so we check and uncheck a box? So, when a box is selected, it looks selected like it would in word (e.g., if you press "Bold" font)

[Patowhiz]

@lilyclements I think it's very possible. WinForms should have a similar toolbar set of controls. Sounds like a good task for @N-thony.

[lilyclements]

@Patowhiz great.

@N-thony what are your thoughts on working on this this week? After more discussions with @rdstern we've decided it might make more sense to have this set of controls on a sub-dialog itself, like this:

In our version, it would look like this

I'll explain this here:

1. A check box that says "Edit text". If checked, then a groupbox titled "Font" is visible
2. In the font groupbox there are eight controls. These are all in the gt::cell_text function.

Text	Parameter name	Parameter values	Control in R-Instat	Other
Font	font	...	editable drop-down
Style	Two functions: weight and style	For weight, options are: "normal", "bold", "lighter", "bolder"; for style, options are: "normal", "italic"	editable drop-down	Give the following options "normal", "lighter", "bold", "bolder", "italic", "lighter-italic", "bold-italic", "bolder-italic"
Size	size	any numeric value	editable drop-down that allows numerical values only	Give the following options: 8, 9, 10, 11, 12, 14, 16, 18, 20, 22, 24, 26, 28, 36, 48, 72
Font colour	colour	...	ucrColour	would that make sense?
Underline style	decorate	NULL, "overline", "line-through", "underline"	non-editable drop-down	In the drop down we say: "None" for NULL
Text transform	transform	NULL, "uppercase", "lowercase", "capitalize"	non-editable drop-down	In the drop down we say: "None" for NULL
Align	align	NULL, "center", "left", "right", "justify"	non-editable drop-down	In the drop down we say: "default" for NULL
Vertical align	v_align	NULL, "middle", "top", "bottom"	non-editable drop-down	In the drop down we say: "default" for NULL

3. A check box that says "Edit borders". If checked, then a groupbox titled "Borders/fill" is visible. The gt::cell_fill and gt::cell_borders functions run
4. In the borders/fill groupbox there are five controls

Text	Parameter name	Parameter values	Control in R-Instat	Other
Fill colour	color	...	ucrColour
Sides	sides	"left", "right", "top", "bottom"	checkboxes	Left, Right, Top, Bottom
Border colour	color	...	ucrColour
Style	style	"solid", "dashed", "dotted", "hidden"	Non-editable drop-down
Weight	weight	numerical values, with px around it	ucrColour	Editable drop-down numerical values only, options of: 0.25, 0.5, 0.75, 1, 1.5, 2

The bottom three are from the cell_borders function, the top is from the cell_fill function.

@N-thony I'm told you're very good at design. Are you also into the coding side too (as in, should I mention the R functions?)

[N-thony]

@lilyclements this sounds good to me, for this week I'm not sure, it is a bit tight. I will have a look of some controls in VS and see which sort of controls will be useful for this. From your above question, yes this is possible as also expanded by Patrick, I don't think we need a special control like for the ucrAxes control to do this, I will start the work and share with you the design first ASAP. You can also provide the R Functions

[lilyclements]

@N-thony - great. This design is actually for two sub dialogs:

1. Format Text
2. Format Footnotes

They are pretty much the same code with a very small difference.

Format Text

R code:

list(
      gt::cell_text(),     # Added if "Edit text" is checked, contains the parameters in the first table
      gt::cell_fill(),     # Added if "Edit fill" is checked, contains the parameters in the second table, just the first one, "color".
      gt::cell_border()    # Added if "Edit border" is checked, contains the parameters in the second table, lines 2-5.
      )

Format Footnotes

R code:

  tab_style(
    style = list(
      gt::cell_text(),     # Added if "Edit text" is checked, contains the parameters in the first table
      gt::cell_fill(),     # Added if "Edit fill" is checked, contains the parameters in the second table, just the first one, "color".
      gt::cell_border()    # Added if "Edit border" is checked, contains the parameters in the second table, lines 2-5.
      ),
    locations = cells_footnotes()
  )

[N-thony]

@N-thony - great. This design is actually for two sub dialogs:

1. Format Text
2. Format Footnotes

They are pretty much the same code with a very small difference.

Format Text

R code:

list(
      gt::cell_text(),     # Added if "Edit text" is checked, contains the parameters in the first table
      gt::cell_fill(),     # Added if "Edit fill" is checked, contains the parameters in the second table, just the first one, "color".
      gt::cell_border()    # Added if "Edit border" is checked, contains the parameters in the second table, lines 2-5.
      )

Format Footnotes

R code:

  tab_style(
    style = list(
      gt::cell_text(),     # Added if "Edit text" is checked, contains the parameters in the first table
      gt::cell_fill(),     # Added if "Edit fill" is checked, contains the parameters in the second table, just the first one, "color".
      gt::cell_border()    # Added if "Edit border" is checked, contains the parameters in the second table, lines 2-5.
      ),
    locations = cells_footnotes()
  )

@lilyclements sounds good

[rdstern]

@Patowhiz and @ChrisMarsh82 I am adding a "table" here as an example. I also note there is a lot of information above and wonder if there are pointers there to something that can be used.
I was using the simple amis data from the boot package, and wanting to check on it. I quickly got 2 useful exploratory tables using the pivot-table dialog. Here is one:

(This was useful for me to check on the "balance" of the data, namely the number of observations in each cell.)

and here is a second:

The odd ordering of the factor on the left, was because I had re-ordered into ascending order of the mean. I wanted to check that it had done this.

However, I also present this, because there are many limitations of these tables (from the R-pivot-table package) compared to what I could do easily if I was only using a spreadsheet for the pivot tables. I still hope that I can get "better" tables, atr least "static tables" from R-Instat than from a spreadsheet!

(By the way I can now copy/paste these data into R-Instat, which is great, - except for the double-headed rows? I have had that discussion also with the Genstat people, with their table stuff, many years ago.)

[rdstern]

@Patowhiz and @lilyclements and @jkmusyoka (copying Lily and James, in case they would like to add or change ideas below)

I have been reflecting on our discussion yesterday. In hindsight I am liking what you have done a lot. I am not sure whether I have a "but", it is more an "and". I would like to see whether we agree on each of my points below. a) There are multiple graph dialogs. I think we agreed there would be multiple Table dialogs? b) There will also be a Tables sub-dialog with many tabs, just as there is a parallel graph sub-dialog. c) It will be a single tables sub-dialog that is called by more than one main tables dialog. So it will be pretty comprehensive, e.g. include a Titles tab. d) The main tables dialogs will include important features, from the (single) sub-dialog, so some neat tables don't need to use the sub-dialog. e) The first tables dialog (which you have been doing, will be the presentation of parts of an existing data frame. This will also become the new Prepare > Data Frame > View Data dialog. This reflects the fact that a data frame already looks like a table, in having both rows and columns. f) It is possible (I hope) that a small extension to your existing dialog, could include nanoplots? If I understand correctly, that would just be a new multiple receiver that includes the set of variables for the plot. There would also be a pull-down for the type of plot. There would be a Hide checkbox. That would be checked by default and would be the option to show, or hide, the variables that are also in the nanoplot. Maybe more is needed? If you agree, then I assume this would be a separate dialog, and this one would not be in the Prepare menu. g) Then we do need another dialog. It is what you called "advanced", but I suggest it will become the main tables dialog. The main difference is in the "columns" receiver. Remember there is a parallel between the graphs and the tables. In a graph you start by asking what columns of data are for the y (the rows), and which are for the x (columns).

Now @Patowhiz I need some clarification, because I agreed with you that we could split the dialogs, so the tables works just on "summary" data. I still don't mind this, but I think we have interpreted "summary data" differently, so I would like to clear that point up first. With the survey data I have a version that includes 2 summary data frames. Here is the first:

I suggest we both agree that is a suitable summary table for gt? Ok so far?

Here is the second:

So this second table/data frame contains the summary values that I thought you would like? It provides the summary data for various tables. However, the data frame isn't in quite the "shape" for the obvious tables, because they will be either 3 by 4 tables (variety in the columns, by Village in the rows), or 4 by 3 tables (Village by Variety). So, I suggest this output, from our summary system is not yet an obvious summary tables by your definition, because you also want the data frame to be exactly the same shape as the proposed gt tables. So my table 2 only works for you if I want tables that have 10 rows?

So, in these tables the columns of the table will be the different levels of the factor(s) that are specified for the columns. My hope is that the Cols and Rows tabs in the sub-dialog can always refer to columns and rows in the table? In the main dialogs the Columns and Rows will be those in the data frame in your current dialog, and they will be levels of factors in the new dialog(s).

So, for me, tables could be pretty data frames, but they could also be data indexed by factors? If so, then my table 2 still complicates your life, i.e. summaries are not enough, it has to be summaries plus reshaping into exactly the columns for the proposed tables? Then your existing dialogs will work.

I am hoping for just my first stage, which provides the data for the table, but a bit of preliminary reshaping might still be needed.

In the gt documentation I suggest the countrypops example indicates what we need (in addition to Patrick's current dialog. In his current dialog I like the MockUp gt article that shows how nicely we could have some of the tables I am looking forward to!

Anyway the countrpops data is a data frame of 13,545 rows. This is summarised behind the scenes into a summary data frame of 51 rows and 6 columns. That's the equivalent of my table 2 above. So that's the initial summary stage. One of those columns is the years (2000, 2010 and 2020). That column then becomes 3 columns, before being made into a gt( ), which is a table of essentially 17 rows. I suggest we need a dialog that starts from the 51 rows, and does the reshaping and then makes it a gt( ) structure?

So I assume the new dialog would have the usual data selector, then possibly 3 multiple receivers on the right, for Row (Factors): Column (Factors): and Data. Possibly the Column (Factors) really have to be factors and if there is more than one column factor, then I assume there would be a spanner? We might start with a single data column, because multiple data columns effectively add another sort of factor, and thery could go across, (columns), or down (rows). If down we would need to say where they fit, with the other row factors. If across then we would also have spanners unless they are the only columns.

The pre-processing will largely be to unstack the column factors, so that a column factor with x levels, becomes x gt columns.

h) Later I suggest we will have another tables summary dialog, that uses the gtsummary package. Perhaps more than one dialog? I suggest the first would use the tbl_summary dialog, and this would start from the original data. This is less urgent and perhaps we could discuss next week, whether Patrick would like to handle all the tables stuff. If not, then perhaps Lily and/or James might help to evaluate this possibility. There are other functions, e.g. tbl_cross and they also overlap with the R-Instat summary system, so this might benefit from more staff investigating?

i) More examples of data for your dialogs: We are assuming data are summarised first (except in point h above. The histdata package (data sets of historical interest) contains quite a lot of pre-summarised data (because they are all from the pre-computer era.) For example Armada has 10 rows and could be presented with your existing dialog. Cholera (38 rows) could be either. Dactyl and DrinksWages would make simple 2-way tables with the new dialog. There are more from that package.

[Patowhiz]

@rdstern I agree with your analysis above. From my deep dive of the gt package in that last few days, it looks like it is purely a presentation package. It expects you to do the margins and transformations then use it for presentation. This is different from pivot tables which have the ability to do the margins and advanced data transformations.

Previously I had the impression that it is capable of doing advanced data transformations but that is not the case. There are packages that extend it to compliment what it was not designed to do; gtsummary, gtExtras, pointblank, tfrmt, gto.

As a follow up, I also agree on the 3 stages that you proposed in the email:

1. Stage 1 is the summary stage from 13000 rows to an ordinary data frame with 51 rows.
2. Stage 2 is a simple reshaping of these summary data into a gt structure. I don’t even want to consider this a data frame, it is a gt object.
3. Stage 3 is the presentation of a gt object nicely.

Note, a gt object depends on a data frame. The starting point is always a data frame, what I mean is, you can't modify a gtobject from a gt object (not unless I'm mistaken). So I think stage 2 and 3 will always start from a data frame.

So we can safely assume that the work I'm doing is purely on presentation tables. If you agree, we can split the tables issue into multiple issues to cover the different stages.

[lilyclements]

To add the spanner R code here as well as #8236 -

library(gtsummary)
library(gt)

summarise_trial <- trial %>%
  dplyr::group_by(trt, grade, response) %>%
  dplyr::summarise(mean = mean(age, na.rm = TRUE))

pivot_summarise_trial <- pivot_wider(xx, names_from = c("trt", "grade"), values_from = mean)

pivot_summarise_trial %>%
  gt::gt() %>%
  gt::tab_spanner_delim(delim = "_")