Greg Swinehart | Designing for people is hard | RStudio (2022)

Well, everybody, my name is Greg Swinehart. I have worked at RStudio for a long time. This is going to be a different kind of talk for RStudioConf because I'm not a data scientist. I'm a graphic designer. Like, I graduated in the social sciences, so why on earth am I up here to talk to you? I'm asking myself the exact same question.

So I started, I think the first design I did for RStudio, I think three people worked there at the time. And I joined full-time about four and a half years ago. I made this back in the day, actually. And this started out as a shirt a couple years before hexes were even a thing. Joe reached out and said, I kind of want to make a baseball shirt with this thing I've been working on. Can you make us a shirt that says Shiny and kind of baseball font? And then when hexes came around, we controversially went with the baseball font where all the other hexes had a different font. It was very, there were some tense conversations, but we got it. Now it's no big deal, of course.

So a few months ago, I moved over to the Shiny team to see what you all have been working on and see if maybe we could update some things in the process. What we're going to talk about today is kind of what I've seen in the last couple months and what we've begun to work on to build some new functionality for you to make your lives a little bit easier. So I'm going to talk about three simple design principles that might help your Shiny apps look and feel a little bit better as you're building them and also show some of the new work that we've just begun to help your apps look and feel a little bit better automatically.

What it's like to be a graphic designer

All right. So what's it like to be a graphic designer? I hate it. I seriously hate it. I hate it. You guys know what I'm talking about. Like you're looking at a thing and it's just not working. It is horrible sometimes. I mean, don't get me wrong. 99% of the time, it's like the greatest thing I could possibly be doing with my time. It's the joy of my life to do it. But then when you get to that thing, you guys know what I'm talking about. Like you have that thing, it just doesn't look or feel right and you start to kind of meddle with some things to try and fix it and there's a million different directions you could go and none of them are working and then it's just like, ah, I hate it.

So I just bring that up to say that I understand what you're going through sometimes when you're making your apps and you're trying to make them look good. We totally get it and we're working on it. We're trying to make this world a little bit easier for you. Here's how I think of design. Design is a form of communication. Communicating well is really difficult. Constructing the perfect message is a lot of work and then if you add the complexity of saying it in a way that your audience will hear or even pay attention to, it can really feel like nearly impossible. So putting an app in front of somebody, in my mind, all the work that you guys are doing, it's like having a conversation with them and that's why I'm here to talk about how designing for people is hard.

Design is a form of communication. Communicating well is really difficult.

Maybe, you tell me, maybe 10% of the work that you're doing when you're working on a Shiny app is front end work and yet you're supposed to have this rock solid data and also an amazing UI and UX experience for your users. That's a really big ask. So our goal here is for you to be able to make better and more beautiful apps and maybe have that even take up less of your time. That's kind of what we're trying to work towards.

Look: upgrading to Bootstrap 5

So when I got to the Shiny team, they asked me one question. How can we make Shiny apps look better? Side question, please tell us it doesn't involve HTML and CSS. Historically, the benefit of Shiny has been you can make something decent without knowing HTML and CSS. But admittedly, as Joe said yesterday, there have been gaps in improving this default look. Joe recognized a long list of people in the community who have stood in this gap like David Grangin and his work on DS4Dash. Without the work of David and how many other people were on that list? It was like a million six. The apps would still look like they were 10 years old probably.

Right now, without adding on some things, a fresh Shiny app can look a little stale. So where do we start? Well, there's two things I want to talk about today. Look and functionality. Look is kind of its default theme and functionality is the components that we're serving up to you so that you can kind of present your data.

Let's start with look, which means we need to have some real talk. Shiny uses Bootstrap 3 to render its UI. And Bootstrap 3 was created in 1852. I don't know the exact date. So Shiny looks stale because Bootstrap 3 this year looks kind of stale. And this is not to speak ill of Bootstrap 3. When it came out, it was a miracle. But if you're going to make a new Shiny app, the best first step you can take right now is to start with the latest bootstrap. Right now, that is Bootstrap 5. Bootstrap 5 will make it look much more contemporary right out of the box. It has more components for us to serve to you. It has better accessibility tools, which is amazing. And of course, it makes your app look responsive and appropriate for whatever size screen it's on.

So how do you do this? You can easily do this. It's almost like I was looking at how they do this. It's literally like somebody said, hey, Siri, make this Bootstrap 5. That's kind of like what they do. And they do it with this R package called BSlib by someone who could only be described as the greatest human being on the planet, Carson Sievert. He has really done. Yeah. This guy has done the Lord's work for like two and a half years to make this process easy for you. You might remember that Joe Chang mentioned BSlib at the 2020 conference. He actually gave a whole talk about it.

So BSlib provides tools to easily customize Bootstrap and therefore your app's appearance directly from R, allowing you to quickly change the appearance of your Shiny apps and for that matter, R Markdown and Quarto stuff. Today, we're going to talk just about Shiny. But it can't be overstated how easy it is to change your Shiny app's appearance to match your organization's branding with just a few lines of code. This is where I come from. We need it to look like Johnson and Johnson. All right. I'm going to look at the red. We got to make it red. We got to look at the typeface. There's a couple key Sass variables that you can target to really kind of change the look of your entire thing. BSlib can make it very simple with one or two lines of code or it gives you access to all 1,400 different Sass variables to change your Bootstrap theme. And so you can go as deep as you want. And this should be in kind of a scalable, reproducible way, right? So BSlib is unbelievable.

Functionality and design principles

Okay. So that's look. You're off to a great start if you update your Bootstrap to Bootstrap 5 with BSlib. Maybe you're putting in a couple colors to match your organization's branding. Let's move on to functionality and get to some design principles that occurred to me while I was looking through kind of any Shiny app I could get my hands on in the last couple months. I've been pouring through all of them from the simplest ones to some of them are behemoths. They're crazy. They're nuts. But everything in there is important. You can't judge it. And here are a few different design principles came to mind while I looked at them. And when I was discussing with the team, we started coming up with new functionality in reaction to those design principles.

So let's get started. The first one comes from the Gestalt principles of design. Now, whether designers know it or not, they're building things with these principles in mind as the foundation. If you're following them, people will be able to easily look at your app. If you're breaking them, you kind of don't want to look at the app anymore. Every designer is using this, whether they know it or not.

So the first one well, actually, I wanted to say that Gestalt psychology is about 100 years old. And it is all about how we process visual information. When you look at something, it turns out you kind of look at the whole of something. You don't look at the parts of it. Like when you look at a bike, you don't go, well, look at that little pedal right there. Well, there's two pedals here. Oh, my gosh. There's wheels right next to it. What's going on here? You don't do that. You look at it and you go, that's a bike. And if you want to know specific things about the bike, you can then zero in. Same thing with web design. You want that whole thing to immediately be something that they want to dive into.

Proximity

So the first principle that I want to talk about here is proximity. Users will mentally group together objects that are spatially close to each other. Now, they're going to do this no matter what. So if you have information on one side of your screen that's discussing something that's on the other side of your screen, they're probably going to group that information with something else over here and then realize, well, that's not quite right. And they're going to start fishing around for what they should group that with. It's really better if you just keep things in proximity. You know, like the most one of the most popular UX books over the last 22 years is called Don't Make Me Think. You know, we're really trying to serve this up in a way so they don't have to process too much. They can just engage with what you're trying to show them in your app.

So what I want to do is kind of show you some things that I saw. I saw this quite a bit and just kind of give you an example of what proximity means. Right here, we've got a paragraph on the left side in the sidebar. And it's speaking about something in this kind of right part of the screen. In a perfect world, those would be closer in proximity. And that thing wouldn't be in the sidebar. That language would be over near the thing that it's referencing. I also saw this. And this isn't horrible. But this is a title that kind of says this, that, and the other thing. And it's talking about the three things underneath that are about this, that, and the other thing. Not horrible. It's kind of nice serving up what's coming below in a platter. But it would be really nice if the this and the that and the other thing were more closely in proximity with the thing they were actually referencing.

And I'm also seeing this quite a bit. There are controls that are kind of somewhere on your screen that control somewhere else on your screen. Inputs and outputs, right? And so I've seen them where it's kind of like you have to start messing with them to see what they control. It would be better if those controls were closer to what they actually controlled.

So let's clean this up real quick. We'll move this paragraph over here, this, that, and the other thing. And this really just says, like, we update this one Wednesday mornings. Let's clean that up a little bit. And let's put the controls actually where they need to be to control something. It's starting to look a little bit cleaner, right? We're causing the user to think less before they engage with this thing.

Order

But do you notice how none of these cards on the screen are the same height? Or in some cases not even the same width? Don't you wish they were kind of sized like this? Where the gap in between, the gutter in between was the same? There's actually a design principle behind this. Maybe you didn't notice it, but now that I've pointed it out, did it kind of make your skin crawl? This is called order. Things that are aligned and symmetrical are more easily processed. When a person opens up your app, you know what? Let's make them not think as much as we can and let them really kind of dive into the meat and potatoes of what you're trying to do, what you're trying to tell them.

All right. So let's clean this up. Got a bunch of things here. All right. This is starting to look a little bit better. With proximity and order, your users spend less time trying to figure out how your thing works and more time using it the way you intend them to. But really, I've just kind of been moving stuff around, right? These are nice things to keep in mind while you're building your app, but your mind is really in other places while you're kind of writing your R code. So we were trying to figure out, is there something here that we can put in the process so that we can kind of put up some guardrails so while you're building these apps, you'll kind of stay in the lane and you don't have to think about proximity because you're kind of just building everything in proximity automatically.

Cards as a first-class citizen

We realized this was the first piece of functionality we should address. It's a card. A lot of cards oftentimes become a dashboard. And from what I can tell, everybody in this room is like the Oprah of dashboards. You're just like, you get a dashboard. You get a dashboard. Look under your seat. We all have a dashboard. So a lot of dashboards everywhere. And I get it, right? You know how to make them. Your users know how to consume them. Everybody wins. Bootstrap 3 didn't have cards. Guess what? Bootstrap 3 didn't have cards. So we decided cards should become a first class citizen of Shiny with NBS lib and that they should look good automatically.

So we decided this. And then, like, we didn't hear from Joe Chang for a day or two. And he came back with a fully-fledged card API for us to put into BS lib. And this is what they look like by default. Pretty simple stuff. You get a card header for a title. This, that, or the other thing. You have a main area for whatever you want. It can be an image, it can be a plot, it can be some pros, a button. Whatever you can think of, throw it in there. And if there's any tertiary information, like we updated this the other day, throw that in the bottom. This does a lot of the design, the proximity, and the order heavy lifting for you.

Check this out. Here's a row of cards, by example. Here's what it would look like. No matter what you put in them, they will be the same height. Because you know what? We're all grownups in this room, and maybe we can have nice things. Sometimes something Bootstrap doesn't offer, but we think is really important, is sometimes you want to be able to tweak the parameters of what is inside the card, or maybe even just kind of change wholesale what's showing in this card. And so you guys are very used to using tabs and menus and drop downs, and so when you put that same code within this card context, it will look like this and give you the functionality of changing what's inside the card.

If you want to make dashboards right now, you're probably using Flex Dashboard, and why wouldn't you? So simple, so clean, for a lot of you, that's all you need. If you want a little bit more functionality, you're probably using Shiny Dashboard, or maybe you're using BS4 Dash. We're building out in BSLib on top of Bootstrap 5 a new UI toolkit for BSLib, and once we're done, you'll be able to use its elements a la carte. You'll be able to kind of grab what you need and not grab the rest. Basically you won't have to import admin LTE to just put a box around something. The things you love about those other packages will be available in BSLib, and therefore you'll be able to use them in Shiny, R Markdown, Quarto. This is more of, Joe called it a library approach, more of a library approach. Grab what you need just right there, and hopefully the design will look good. If you need to change some of the branding, go for it. That's pretty easy too. Not everything needs to be a dashboard, but bringing in a little dashboard element now and then to your app can be a pretty powerful thing. Pretty good thing for your users.

Information architecture and user personas

So let's talk about your users. The last thing I want to talk about is just information architecture. Not from Gestalt, but it's when you look at your app, let's say you've narrowed down all of the content to as little as it can be, and it's still kind of a mess. It's still kind of hard to engage with. This is where you can start kind of prioritizing what you show based on the users that you're going to be presenting it to. Any app you make, any website you make, any poster you make, you can probably prioritize who is going to engage it. You can come up with like three or four different, three or five different users. A lot of people call them personas.

So let's prioritize based on who's going to be using it, and just show them what they need to know. The way that's easiest to prioritize for your different users is by how much time of theirs you have. Some people are going to be looking at your dashboards, maybe like a boss is looking at a dashboard. They have 30 seconds to get, you know, the main headlines, and then they're moving on to check out like 15 other dashboards at 15 other departments. Maybe there's a department leader that has a couple minutes a couple times a week. They probably need to know everything that the boss needs to know. They probably also want to know a little bit more. So that stuff that they need to know, if it's too messy initially, it's okay to kind of put that away behind the click. There's probably a third person who's a specialist, might spend all week, every week in your app and need to respond in real time to what's happening there. They might need to really kind of drill down and see some very specific things that are happening. And so that is okay for them to click behind the thing.

Live demo: BSlib in action

So what I want to do is I want to show you what BS Lib looks like in a live example here, the stuff that we've been making. So we've got this sidebar here, and we have decided that we had too much in our sidebar, so we've categorized them into five different accordion menus. We're bringing in accordions. You can have them open or closed. Because we think the boss would want to engage with these first two, we open up those and we close the rest. Accordions are going to be a thing that you can kind of put in wherever you want. It doesn't have to be in the sidebar.

All right. So now we're going to engage with this a little bit. We're going to bring in button groups from Bootstrap 5 that can also act as checkboxes or radios. So in this app, there's three different airports. Let's see. Where do we want to fly to? I obviously want to fly to Hawaii. And I don't know where Bob Hope is. Is that Palm Springs? I like Bob Hope. So we'll do that. All right. So just for fun, let's close these because that's fun. Here's another thing we can do. We're working on some histograms that show with range sliders. So we can bring some more meaning to a range slider, let people kind of investigate the data a little bit that way. And this is all kind of changing what's showing on the right.

Now, let's move on to the cards here. Cards are amazing. Sometimes people put a lot of cards on a page. It can get to be a lot. My kind of rule of thumb is if you reach seven cards, maybe it's time to start looking at making a new page. But in this case, we've got this globe here, and it's kind of showing some data. And it's a little hard to kind of make out what it's doing. So we've added a full screen feature to make a card go full screen. And so now you can kind of play with this with a bit more real estate.

That card to the right, I zoomed in and I was able to see a bit more information. I'm about to get the light here. So I want to talk about value boxes real quick. We're going to make value boxes. You can put an icon up in the corner. It's just kind of an HTML space. I was sitting next to the dude who made Plotly. So I said, can we have a spark line for an icon? He said, sure. This is great for the boss who is looking at this. But maybe you want to be able to click in and see a bit more. So value boxes can be full screen. And you can kind of see more information. I don't know if you noticed, but now there's an X and Y axis. You can show more stuff.

All right. I'm about to get the gong here. So let me just say, I think this will be especially powerful when it comes to tables. All of this comes from conversations with you. We'd love to hear from you and find out what you're struggling with and how we can maybe help. So reach out. My email is greg at rstudio.com. And I'd love to hang out.