We want GREAT tables! | Richard Iannone & Michael Chow | Data Science Hangout

Transcript#

This transcript was generated automatically and may contain errors.

Welcome back to the Data Science Hangout, everybody, and Happy New Year, if I haven't had a chance to see you yet or say that. If we haven't met before, I'm Rachel and I lead customer marketing at Posit. If Posit is new to you and you're joining this Hangout, Posit builds enterprise solutions and open source tools for people who do data science with R and Python. We're also the company formerly called RStudio . I like to add that in there too. But I'm joined by my amazing co-host Libby as well. Hello everybody, I'm Libby. I'm a community manager here at Posit helping to foster our Hangout community and help host the Hangout. And I'm also a Posit Academy mentor where I help professionals do more with data by learning how to use R and Python in their jobs.

So happy to have you all here with us today. The Hangout is our open space to hear what's going on in the world of data across all different industries, get to chat about data science leadership, and connect with other people facing similar things as you. So we get together here every Thursday at the same time, same place. So if you are watching this as a recording on YouTube and you want to join us live in the future, there will be details to add it to your own calendar below.

Thank you so much to those of you here who have helped make this the friendly and welcoming space that it is today. I love getting to see that people are now friends from the Hangout and getting to chat with each other here in the Zoom chat. We're all dedicated to keeping this that friendly environment. So if you ever have feedback about your experience or anything at all that you want to share with me anonymously, good and bad, or even suggestions for topics to dive deeper on, I will share a Google form in the chat with you right now. You can always reach out to me on LinkedIn as well.

And at the Hangout, we love hearing from you. This is a community-driven discussion. This is not like a podcast where Rachel and I are hosting. The questions come from all of you. So we really, really encourage you to get together in the chat, connect with other attendees, briefly introduce yourself, where you are, what you do, what you do for fun, share your LinkedIn, share a link to your website, all of that stuff. And we love hearing from you, no matter your years of experience or your title, your industry, what languages you use or don't use, this is a place for you and we want you to know that this is a place to like hang out with each other and us.

There are three ways to jump in today and ask those questions to get things started. You can raise your hand in Zoom. We'll call you to just unmute and ask your question. You can put your question in the Zoom chat. We will call on you to unmute and ask your question. If you happen to be somewhere where you cannot talk or your mic doesn't work, just put an asterisk somewhere in your question and we'll ask it for you. There's also a Slido link. You can ask questions anonymously if you feel like and that's totally fine as well.

And this blog post really served as almost like a calling card, like a way to explain really easily to people what am I doing, and with the hopes that if they know like a colleague that they'd be able to just pass it to them too.

Excel-to-gt workflows and table templates

Nice. That's a great tip. I see, Stephanie, you asked a question a little bit earlier. Do you want to jump in here first? Of course. I'm in the middle of eating lunch. Yes, no problem. So my question relates to like a current workflow we have at work that will have people who are not data people make table templates in Excel to define analyses. It really helps us know what they're looking for in an analysis. And then we have someone run the analysis to populate the table. And we use OpenXL SX for this right now. But it would be great if they could somehow make templates that would work with a gt workflow, but they're not our people. And has there been any thoughts about that? Are you saying going from like Excel to gt? Yeah. There's actually a package out that does pretty much this. And like, I didn't put in the gt, like read me like I do for other packages that use gt. I think it's called GTS or something to that effect. And I forgot and I feel bad for not knowing this, but there is like a new, it's new. Like it was just out in the last two, three months. But yeah, it's sweet. It goes from Excel to gt. I'd love to have the other way going. And that's kind of like a thing of promise to the law back, like having gt to Excel. But I think this seems to fit exactly what you need. At least check it out.

Can you do it without data that pre-exists? Because we struggle, sorry I'm so glad you asked this question. We struggle with the same thing, right? And so we're often trying to just come up with like synthetic data to populate a table to then replace it with like a bunch of X's and like placeholders, right? But I really wish there was a way to just come up with a shell that didn't presuppose data exists. Yeah. And I think some approaches take like, have that like gt reg, not gt reg. There's another package that basically populates, has like a plan for like, and doesn't require data. You basically just start with like a template, exactly what you said. And it's a pharma package. And the name totally escapes me again. I'm really bad at coming up with gt affiliates. I see Daniel's, Daniel's going to know. Daniel, what is it? Please Daniel, help me out here. So we're building in the pharma space. We're working a lot with something called Analysis Results Datasets right now. And it's very, very easy to build an empty ARD. That's the Analysis Result Dataset. And if you have an ARD, then you can go straight to tables via gt summary, which we're also kind of generalizing to be able to do kind of anything at this point with ARDs.

ShinyLive compatibility and dependencies

Yes, I'm coming off mute. So one, I had a question because I posted an issue. The most recent version of Great Tables broke ShinyLive compatibility. And I'm just curious how important it is to y'all to keep ShinyLive working with gt. It's the new dependency on CCS inline that doesn't work. So I posted an issue in the GitHub. I just thought I'd mention it here since I got the ears of all of you. And then so you can address that. But at a high level, I do like Great Tables. I've started using it more and more. I think I'm a Python person. So I didn't really use it on the R side. And I posted another comment, I think, recently about bootstrap styles, which I think someone responded to. And I appreciate that feedback. But just at a high level, I just want to encourage you all to think about tables as more than just for numbers or even charts. I use tables a lot in a lot of my web apps and stuff. And obviously, I put buttons in tables. I need links to be conditional on other columns and tables. So just think big when you're thinking about tables. Because I feel like a lot of table packages really focus on formatting numbers or whatever. And you support markdown, which is great. And that really helps me for some things.

Yeah, I totally agree. And I'm doing that, too, actually, using Great Tables as software or something for something else. And you need to go into the guts of Great Tables to tease out a few things you need to program tables. So you can definitely expose more of those things if you want, maybe create an issue for that. And I saw your issue on CSS inline. And what you can do is make that an optional install, because that raw, as raw HTML, doing that one trick of inlining CSS, that seems very extra. So we can definitely make that one package an optional install, so you don't have to break ShinyLive. So that's something we can do. Very cool. Yeah. I do think, too, on the ShinyLive note, now that ShinyLive, so we went on this big arc where another engineer at Posit, George Stagg , just got Polars working in WebAssembly. So ShinyLive, I don't know if now or very soon, should support Polars. Yeah, I'm very excited. I'm very excited about that. I actually rewrote a bunch of code. I had a ShinyLive app and I rewrote a bunch of code to use pandas because I couldn't use Polars in ShinyLive. And then a week later, they were like, oh, Polars is going to work in PyEditor.

Yeah, yeah. So I think that's one of the reasons we haven't been using ShinyLive too much either, is we've been using a lot of Polars in our docs and just working with Great Tables. But now that ShinyLive does or will really soon support Polars, I think we'll start using it quite a bit more for examples and demos and things like that. So hopefully that'll let us kind of keep it in the loop a bit tighter to keep an eye on these kinds of breaking changes. Yeah, and I think we're generally trying to reduce dependencies, like the trail of dependencies on Great Tables. We should do the same thing for gt, but for Great Tables, at least we're going to try to get rid of some things or replace things that make it heavy because of issues like this, essentially.

Table design resources

Oh, sure. Yeah, so I asked it in chat. Just curious if you all have any resources for papers or books on table design principles. I'm putting together a workshop. It's kind of a two-part workshop with table design principles and gt Great Tables. Oh, yeah. We got stuff. We got stuff. There's this old thing that we talk about all the time, this 1949 manual of tabular presentation. It's a goldmine for ideas. I know it's old, but actually it's got a ton of good stuff that's relevant today. For a newer thing, right behind me, there's this book. I'll show me the numbers. Look at this. It even has tables on the front cover. That never happens. I literally bought that on Amazon yesterday. Excellent. Yes, a great book. Of course, it has more on plots, like rafts, they call them, but it has tables, which is amazing. And so there's good stuff there. Other than these two things, it's kind of hard. We've been looking. That's not like we haven't tried. There's not much. Maybe that's where we step in. I don't know.

Reporting issues and contributing

Okay, thank you. So I swear this is not an attempt to make you troubleshoot my Great Tables heat map problem on this call. But it was New Year's Eve, and I was trying to get my table to work, and I couldn't. But my question is really, like, how much work do we need to do in issues to make it useful for you guys when we're reporting an issue? Because I totally, like, did not do the thing where I made it reproducible and reported it on GitHub, because I was like, that seems like a lot of work. So like, how much work do we need to do? Like, what do we need to get you in order to give you an issue that you can actually do something useful with? Well, I think not much. Just, like, we can get the conversation going. Just maybe a screenshot and maybe some code, and then we can just discuss and then, you know, zero in on the actual issue and what needs to be done. Trick is just to start. Don't be shy like I am all the time with issues. Just get in there, and we'll eventually get to the harder problem.

I feel like Rich is way better at the social media connecting, but I do feel like I don't think it hurts, like, to just open an issue, and if you're in the middle of it, just mention. Like, you could, you could have a single sentence that just says, like, super fast what you're seeing. And I think that's totally fair, because worst case, we just ask for more information. I think best case, like, we actually can just read that sentence, and it's, like, something we've thought about or can point to more information. I think that's fair. Like, it's very fast to kind of, like, scan a sentence and either ask for more or, like, maybe we actually know something about it and can help you, like, out right away. And something super effective is just, like, a screenshot marked up with, like, lines or desired things. I've seen that a bunch of times, and that's actually way better than a text description half the time. It just really just gets right to it.

Building and publishing packages

And kind of on this same thread of, like, anxiety or nerves around doing stuff like this, I wanted to ask both you, Rich, and Michael, how many packages did you develop secretly or privately before you were actually comfortable publishing packages and putting them out there and letting people see them? And how many do you have just, like, sitting in the wings or the back burner that you don't talk about? Michael, you go first.

It's such a great question. So many. I just feel like, well, I feel like the frequency of packages has stayed the same. Like, lots of small packages, like, year to year. I would say there's, like, so many, like, pour one out to the ones that didn't make it even out of the gate, like, that are, like, a repo with just an idea where I had a big dream and then gave up on it right away. So I think to your question, like, how many packages have I done before, like, releasing things? I think that so many because I think it's good just to get into the habit of building packages. And, like, it's okay to do it in the open, but I would say there wasn't really, like, a turning point where I was, like, now I can start releasing good packages to the world. I think I just did really bad packages and they got, like, better and better over time. And now there's, like, a healthier mix of, like, good and bad packages. But I would really lean into the joy of putting a bad package into the world as kind of, like, I think at the worst, a bad package is almost like a blog post, like, and giving them a lot of, like, work that you did.

I would really lean into the joy of putting a bad package into the world as kind of, like, I think at the worst, a bad package is almost like a blog post, like, and giving them a lot of, like, work that you did.

So I would say so many packages and still doing a lot of bad packages today. I don't really do them under the radar as much. I try to just do them as a public package. So learning out loud. Yeah. Yeah. Yeah. So much of our advice has come down to, like, just do it anyway, even if you're nervous about it. Rich, what about you? Yeah. I started this, like, 10 years ago, probably around the same time as Michael, maybe a little over 10 years ago. Doesn't matter. A lot of bad packages. I mean, I was learning stuff at the same time, so I didn't mind. But I saw people doing stuff out in the open. I was, like, I want to do that, too. It was great. And, like, some people actually use the packages, the early stuff that I wrote. And, like, it was fun to interact with people and just get to know people. So that was even better than, like, writing the package half the time. It's, like, interacting with people. It's, like, oh, my God, this is amazing. And they would help you out. Blew my mind that people would help out. So, yeah, no regrets about bad packages.