Speaker 1: Hey, everyone, Welcome to another episode of React Round Up.
Speaker 1: I will be your host today, Paige Nee Dringhouse, and
Speaker 1: we are joined by one of our panelists, TJ.
Speaker 2: Van Tool.
Speaker 1: Here everyone, and our special guest for today is Katherine
Speaker 1: Grayson NaN's Katherine, Do you want to introduce yourself and
Speaker 1: tell us a little bit about why you're famous? Absolutely?
Speaker 3: First out, thank you so much for having me. I'm
Speaker 3: super excited to be here.
Speaker 1: I am a senior front end engineer at threat Connect
Speaker 1: and I'm here today talk about component libraries. That's been
Speaker 1: kind of my jam recently, a place that I've really enjoyed,
Speaker 1: kind of working, getting to combine some of the skills
Speaker 1: from my design background with some of the technical aspects
Speaker 1: of being a friend end engineer. It's kind of been
Speaker 1: a niche I've found that I've really enjoyed and gotten
Speaker 1: the chance to give a couple talks on and build
Speaker 1: a couple libraries at a couple different companies. Now excited
Speaker 1: to share that's actually really interesting. I have used a
Speaker 1: number of component libraries Bootstrap, ant design material, UI. How
Speaker 1: do you actually go about building a library? Though? That
Speaker 1: is that seems like a pretty large undertaking. It is
Speaker 1: and I think it's worth saying first that it's not
Speaker 1: an undertaking that everyone needs to do. Like you said,
Speaker 1: there are a lot of really great libraries that really exist,
Speaker 1: and if you're just getting something off the ground or
Speaker 1: really trying to iterate quickly, then there's a lot of
Speaker 1: value in material design or ant design, they're good libraries.
Speaker 1: But it's also true that if you are at a
Speaker 1: larger company, or you have an application that has some
Speaker 1: different requirements or has a lot of custom components that
Speaker 1: you find yourself using and reusing that might go beyond
Speaker 1: your basics, your button, your drop down, then it can
Speaker 1: be beneficial to have all of those in one place.
Speaker 1: Really get to control the design, control puts, the props
Speaker 1: that are passed in, getting to handle all the things
Speaker 1: that are kind of custom to your library. And you
Speaker 1: forgive me, you.
Speaker 3: Know, as I said, inputs, which is because I've swapped
Speaker 3: recently this new job. We're working in Angular, which I
Speaker 3: know is probably heresy to say on the reactor. So
Speaker 3: I'm in the weird place now where I'm using all
Speaker 3: the React terms when I talk about Angular, and now
Speaker 3: using all the Angular terms when I talk about React, messing.
Speaker 2: Up both that actually gets me into question like how
Speaker 2: deep when you like when you say component library, right,
Speaker 2: like what specifically are we talking because does does this
Speaker 2: actually get into like React code are we talking about
Speaker 2: just like CSS and HTML or does it kind of
Speaker 2: depend on specifically what you're implementing At least in.
Speaker 3: My case, I'm definitely talking about code, so creating those
Speaker 3: kinds of custom components, and it does also include jsex
Speaker 3: and CSS or whatever your flavor of styling is, sass
Speaker 3: or less or whatnot. There are definitely component libraries that
Speaker 3: you can create fully in Stigma or your design platform
Speaker 3: of choice, and those are valuable in that they help
Speaker 3: you narrow down your design style, your colors and your
Speaker 3: type faces and really getting that kind of cohesive look happening.
Speaker 3: But when it comes to actually being able to reuse
Speaker 3: those components that React is just made so well to do,
Speaker 3: they can help to actually put those all together into
Speaker 3: one shared library and be able to important max building
Speaker 3: so fast. So have the libraries that you've built are
Speaker 3: they actually built with React? Because I've there's one in
Speaker 3: my company that's built with web components, because we have
Speaker 3: teams who build with Angular with few with React, and
Speaker 3: they wanted something that could kind of work with all
Speaker 3: of them, and it's it's okay, but it's been a
Speaker 3: little bit painful to implement because it's not actually React code.
Speaker 1: So is yours? Like, is it specific to a particular
Speaker 1: framework the kinds that you've built. Yes, I've done one
Speaker 1: in React and I'm currently in the process of doing
Speaker 1: one in Angular. I agree.
Speaker 3: If you're in a situation where some of that stuff
Speaker 3: needs to be shared across you gain a little, you
Speaker 3: lose a little. It's about that kind of compromise.
Speaker 1: But if you are just working in one framework, then
Speaker 1: it's nice to be able to have that specificity and
Speaker 1: really build things in the way that you know exactly
Speaker 1: how they'll be used.
Speaker 2: So I'm wondering if you could help paint me a
Speaker 2: picture of like what using a component library like. Well,
Speaker 2: first of all, is this like if for internal usage
Speaker 2: or these things you're like publicly documenting. And then then
Speaker 2: I'm sort of curious, like what's the use case like internally,
Speaker 2: Like I'm I'm an employee, I need to work on
Speaker 2: a new app. I need a button, Like what's my
Speaker 2: experience like, is it like using like a material or
Speaker 2: a design button? There is it a little bit different?
Speaker 2: What do I install? And I'm sort of curious about
Speaker 2: that sort of stuff.
Speaker 1: Yep, for sure. To the first part, whether it's something
Speaker 1: you want to share publicly or not, it kind of
Speaker 1: depends on the company. I know that that's super common now,
Speaker 1: and the idea of like, oh, we'll make it and
Speaker 1: we'll open source it and then everyone can use our components,
Speaker 1: which is one of those things that I think, honestly
Speaker 1: is nicer in theory than in practice. The idea of
Speaker 1: sharing your wonderful work with everyone and contributing to the
Speaker 1: design world sounds great, but you actually give yourself just
Speaker 1: a whole ton of upkeep and new variables to consider
Speaker 1: when you're not just building for your own company in
Speaker 1: a limited use case that you have probably a stronger
Speaker 1: understanding of, right, So you then end up in this
Speaker 1: situation where you're like, well, we know that we're going
Speaker 1: to use our component this way, but what if someone
Speaker 1: else wants to use it in some other way? So
Speaker 1: you broad things and you end up kind of creating
Speaker 1: I think, less specific and useful components because you're catering
Speaker 1: to a potential audience that you don't really know. If
Speaker 1: you have yet.
Speaker 3: So I would say if you have a library and
Speaker 3: you want to eventually go back and open source it,
Speaker 3: and especially if you're working somewhere you know, real big,
Speaker 3: you hear about kind of the you know, the Airbnbs
Speaker 3: of the world or whatever that share THEIRS. But not
Speaker 3: not to sound dismissive, but I'm not sure every company
Speaker 3: needs to share THEIRS. I think it's a huge accomplishment
Speaker 3: and a great thing in and of itself to build
Speaker 3: something for your company that suits the needs that you
Speaker 3: have and it doesn't need to be global.
Speaker 1: Honestly.
Speaker 2: Yeah, it's actually some interesting points I didn't consider, because
Speaker 2: I mean, the whole idea behind doing this is you're
Speaker 2: customizing something more than what you'd find in the general web.
Speaker 2: So I could totally see conversations of, well, we want
Speaker 2: to bring our logo into this component, but oh wait,
Speaker 2: this is like for the open Web, and what if
Speaker 2: they don't want our logo? Now we have to make
Speaker 2: this generic. And it seems like you get yourself in
Speaker 2: the more complexity than you cared for concerns that aren't
Speaker 2: specific to your company right away.
Speaker 3: Yeah, I will also say my last company, we didn't
Speaker 3: share our code publicly. So it was not open source
Speaker 3: and that other people could use our library, but we
Speaker 3: had shared it publicly so that you could go look
Speaker 3: it up online and you could go look at all
Speaker 3: of our components and like see the styles, and that
Speaker 3: helped us when working with freelancers and explaining things to clients.
Speaker 3: We used it a little in fact, for doing some
Speaker 3: like quick prototyping and click testing with users, which I'll
Speaker 3: circle back.
Speaker 1: To because I've got a lot to say on that one,
Speaker 1: but it'll I'll track us.
Speaker 3: But even then, just knowing that it would be out
Speaker 3: there on the web, we ran into some things where
Speaker 3: we were like, we're not really sure that we want
Speaker 3: to make that even visible, some questions of like IP
Speaker 3: or things that were super specific to our app or
Speaker 3: things that we wanted people to you know, pay to
Speaker 3: have access to, and be like, well, we are we
Speaker 3: giving too much away? Are we're showing too much? You
Speaker 3: kind of start to walk that line. I think in
Speaker 3: addition to that fear of generalizing the components, we ended
Speaker 3: up solving it there by basically creating two versions of
Speaker 3: the library, like a public and a private. So the
Speaker 3: version that we actually put out that you can type
Speaker 3: in the URL and see does not include some of
Speaker 3: the more private and specific components that we wanted in
Speaker 3: the library for developer use but didn't want to be
Speaker 3: on the on the global stage. Basically, gotcha, it's really interesting.
Speaker 3: So one thing that you mentioned towards the beginning was
Speaker 3: when you got to a point of components having very
Speaker 3: specific functionalities that you know generally you couldn't find in
Speaker 3: like an existing library. So can you give some examples
Speaker 3: of what that.
Speaker 1: Kind of functionality might be that you that you encountered
Speaker 1: that you're like, we just we need to build this
Speaker 1: ourselves because nobody else really does something like this currently. Yeah.
Speaker 1: I found a lot of those to be a kind
Speaker 1: of specific to what your company does and what you're building.
Speaker 1: The last company I worked at was a place called Hermann,
Speaker 1: and they do what's called a thinking assessment, which is
Speaker 1: kind of similar to Myers Briggs, which they'll hate me
Speaker 1: saying if they hear this, but where you kind of
Speaker 1: take an assessment and then it gives you some information
Speaker 1: back about your thinking preferences and how you tend to
Speaker 1: problem solve. So let's be a personality thing more of
Speaker 1: a thinking thing, but in order to share those results
Speaker 1: there's kind of a visual language and even just an
Speaker 1: act technical language that's used. There's a specific set of
Speaker 1: colors that's used to designate strengths in different areas. Those
Speaker 1: things were just so specific to what the Herman platform
Speaker 1: needed to communicate that there's no way it wouldn't make
Speaker 1: sense for anything like that to be in material design.
Speaker 3: But at the same way, there were components we were
Speaker 3: using over and over and over again to show people
Speaker 3: their strengths, their weaknesses, their dominant you know whatnot the
Speaker 3: way their profile broke down, their preferred methods of communication,
Speaker 3: the stuff that came up over and over again within
Speaker 3: the application that we needed to kind of get down
Speaker 3: and codify in that way for the ease of our developers. Yeah,
Speaker 3: that totally makes sense when you when you describe it
Speaker 3: a little bit. That's really interesting though, So when you
Speaker 3: are or have been working on these libraries, are you
Speaker 3: building the library and then also building an application that's
Speaker 3: using it, or have you been able to like focus
Speaker 3: specifically on one or the other, because it seems like
Speaker 3: those are two full time jobs by themselves.
Speaker 1: Usually it has been more not usually both times, it
Speaker 1: has been building both the application and the component.
Speaker 3: Library, which I actually think is the right way to
Speaker 3: do it. You're right, that is a it's a lot
Speaker 3: of work, and I want to be clear that I'm
Speaker 3: not the only one contributing to these projects on these teams.
Speaker 3: In both cases, I've been kind of the project lean
Speaker 3: and I've gotten the opportunity to kind of shape it
Speaker 3: and come in with that expertise and say, here's how
Speaker 3: we're going to do it. These are the steps we're
Speaker 3: going to take. But it would not have been possible
Speaker 3: without my teammates and the other folks that were equally
Speaker 3: invested in getting it off the ground and in building
Speaker 3: components and testing components and filling in that kind of
Speaker 3: knowledge and expertise that's needed. But kind of circling back,
Speaker 3: I think it's best to work on both, honestly, because
Speaker 3: you need to have a feel for how the components
Speaker 3: are really going to be used, and you need to
Speaker 3: be putting them into use to be able to kind
Speaker 3: of validate that they are needed, because a lot of
Speaker 3: times when you start you kind of think, oh, I
Speaker 3: need all of these components, because you know, material design
Speaker 3: has all of these components, but you probably don't need
Speaker 3: every single component that's in material design, but you know,
Speaker 3: designed to look like your brand. You can pick and
Speaker 3: choose things that you'll actually use. You can narrow down
Speaker 3: use cases rather than like creating everything and just hoping
Speaker 3: it will be used. If you're actually in the application
Speaker 3: and you're working with the application code all the time,
Speaker 3: you can get a better feel for what's really needed
Speaker 3: and what's not needed and what's just going to be
Speaker 3: filler that you'll have to maintain forever.
Speaker 2: So thinking of the components and developing side by side
Speaker 2: with another app, so are these components that live like
Speaker 2: in like their own repo sort of thing, and like
Speaker 2: is each individual app that your company uses like pulling
Speaker 2: them in or there's some other sort of workflow in place.
Speaker 3: That is how it's been set up in both cases
Speaker 3: is to have them in their own repo that does
Speaker 3: kind of come with its own lift that I know
Speaker 3: worries a lot of people at first, because again, when
Speaker 3: you're starting off, it feels.
Speaker 1: Like a huge task to begin with to put together
Speaker 1: a component library, and then you have to think about
Speaker 1: and I have to have this whole other repo and
Speaker 1: how am I going to bundle these things?
Speaker 3: But how am I going to export and import. Sometimes
Speaker 3: the easier mode is to just have a subfolder in
Speaker 3: your application, especially if you've got like a mono repo
Speaker 3: thing where all of your applications can kind of share that.
Speaker 3: That can be a really great place to just kind
Speaker 3: of get your feet wet and to kind of prove
Speaker 3: the need for a component library and to get other
Speaker 3: people invested, which is a huge, huge, huge, huge part
Speaker 3: of the lift. It's just getting other people to see
Speaker 3: the value and to get on board with the idea.
Speaker 2: Yeah, I'm actually wondering if you could talk a little
Speaker 2: bit about like the corporate politics of this, because I
Speaker 2: have to imagine, I think Page It's really where you
Speaker 2: were maybe going with this too, because like I think
Speaker 2: all of us on this call sort of get it
Speaker 2: right because we're coming from this sort of background. But
Speaker 2: I'm curious if you've had run into problems of trying
Speaker 2: to get teams, like especially in larger companies, right you
Speaker 2: have different teams doing different things, Like what sort of
Speaker 2: issues have you run into trying to get everybody to
Speaker 2: use these components, like contribute to them, stay consistent and
Speaker 2: that sort of thing.
Speaker 3: I think the biggest issue is getting everyone on board
Speaker 3: it first. Because most companies, without kind of realizing it,
Speaker 3: have started to build a library, without thinking about building
Speaker 3: a library, Almost every almost every application I've poked around
Speaker 3: and has that shared components folder. That is a good start,
Speaker 3: and it's where you should look. And if you start
Speaker 3: seeing that get really, really busy, then maybe that's a
Speaker 3: sign that a component library can be a good fit
Speaker 3: for you. But there's a huge lift in terms of
Speaker 3: splitting that stuff off, right, because once you pull those
Speaker 3: out into their own repo, you have to make the
Speaker 3: decisions in terms of what part of this component needs
Speaker 3: to stay, what of this is really business logic it
Speaker 3: needs to be in the application versus what's presentational. How
Speaker 3: is the refactoring process going to work. How are we
Speaker 3: going to handle just getting everything swapped over that first step.
Speaker 3: The first steps a doozy, But what I try to
Speaker 3: do to get people on board is to really focus
Speaker 3: on the outcomes, right and to kind of be realistic
Speaker 3: about what that first step is going to be. That
Speaker 3: you don't go in with delusions of grandeur that we're
Speaker 3: going to have this setup in a week and then.
Speaker 1: It'll be amazing.
Speaker 3: That this is going to take some upfront effort and
Speaker 3: that every small victory kind of along the way is
Speaker 3: something that we should celebrate. And in the end, we're
Speaker 3: aiming for this goal. We're aiming to have x number
Speaker 3: of components in use in the application, and it will
Speaker 3: help us in these specific ways. And the more you
Speaker 3: can kind of nail down we're making a component library
Speaker 3: because we need visual consistency, or we're making a component
Speaker 3: library to help us coordinate with the design department, or
Speaker 3: to help us do user testing, or to help us
Speaker 3: tackle accessibility issues, like the more you can set specific
Speaker 3: goals for your company and use the component library as
Speaker 3: a path to meet those rather than the component library
Speaker 3: being the goal in and of itself, the more you'll
Speaker 3: be able to give people on board with kind of
Speaker 3: your vision and why you're doing it and help them
Speaker 3: see the value in the long game.
Speaker 2: I really like that angle because I think every single
Speaker 2: company I've ever worked for has had the issue with oh, look,
Speaker 2: our header looks different in these eight applications in these ways,
Speaker 2: or what do you know, we're using seven different fonds,
Speaker 2: or like our button, there's no consistency. So I like
Speaker 2: that sort of as an inroad to making the argument
Speaker 2: is like it's a path to getting there rather than
Speaker 2: just trying to share things for sharing sake.
Speaker 3: Yeah, that's definitely, and in fact, that kind of discrepancy
Speaker 3: in the UI is one of the first steps I
Speaker 3: like to take in terms of sitting people down and
Speaker 3: helping them figure out what components will be valuable to
Speaker 3: start with, because again, the best thing you can do
Speaker 3: is to start to show that value as soon as
Speaker 3: humanly possible. As soon as you can start to get.
Speaker 1: That ROI on your library, then the more people will
Speaker 1: be invested in kind of snowballs, And that's the effect
Speaker 1: that you want. I like to encourage people to sit
Speaker 1: down and run basically a UI audit on their application,
Speaker 1: and to go through and take screenshots of all the
Speaker 1: different heads and all the different buttons and all the
Speaker 1: different dropdowns, because when you see all of those in
Speaker 1: one document next to each other, it's usually enough for
Speaker 1: people to go, oh, okay, yeah, I see what you
Speaker 1: made me. Maybe we do have a problem. That's where
Speaker 1: I can ask, because how would you go about doing
Speaker 1: a UI audit if you if you're you've never done
Speaker 1: one before, because I have not, so I'd be interested
Speaker 1: to learn, like, what are the steps for that? So
Speaker 1: credit where credit is do the idea of a UI
Speaker 1: audit is Brad rost Okay, so I want to throw
Speaker 1: that out there. He's got some really good resources on
Speaker 1: running one. But the way that I like to do
Speaker 1: it is to basically almost make it like a game,
Speaker 1: set some time aside and kind of make some different
Speaker 1: categories in like a shared board, like a mirror board
Speaker 1: or you know, a Google slidestock, be like, all right,
Speaker 1: here's the page for headers, here's the page for buttons.
Speaker 1: You're going to go on a scavenger hunt in our
Speaker 1: application and take pictures or screenshots of every single one
Speaker 1: that you find, and it ends up being it's kind
Speaker 1: of a fun thing because you go and everyone's see
Speaker 1: yeacking while you do it. And then when you get
Speaker 1: that and you have everything documented, you have the woe moment,
Speaker 1: which I think is important for everyone to see, like, wow,
Speaker 1: we have twenty of these, and then you can really
Speaker 1: start to talk through well why do we have twenty
Speaker 1: of these? Is this one serving a different purpose than
Speaker 1: that one? Does this do something the other one doesn't?
Speaker 1: Is there a feature that's a part of this? You know,
Speaker 1: both of these look like dropdowns, but one's actually a
Speaker 1: multi selector in a list, you know, and we need that,
Speaker 1: and that's a separate component that I dropped down, and
Speaker 1: that helps you kind of isolate what's happening and where
Speaker 1: it's being used and if there was any reason behind
Speaker 1: all those different versions, because a lot of times, you know,
Speaker 1: we think like, oh, someone was just lazy and coded
Speaker 1: their own styles, and there's usually like a bit of that,
Speaker 1: but more often it's people trying to solve different use
Speaker 1: cases with the skills that they have. So they see
Speaker 1: a button and they're like, oh, this button is almost
Speaker 1: the same, but I actually also need it to do
Speaker 1: something else when it's clicked. So you end up with
Speaker 1: a button that looks a little different because they took
Speaker 1: a button, but then they tweaked it because it had
Speaker 1: to do this other thing, and then you hit up
Speaker 1: with twenty buttons.
Speaker 2: Wondering could you talk a little bit about some of
Speaker 2: the tools you use for making this sort of thing
Speaker 2: possible as well? Or is this just quite literally you
Speaker 2: have like my company component library and then like a
Speaker 2: folder for each components. Are you using things to sort
Speaker 2: of help you build this.
Speaker 3: I'm a big, big, big fan of storybook in terms
Speaker 3: of building out your component library. They have a really
Speaker 3: great system. They make it really easy to pick up
Speaker 3: and start going in terms of organizing your components and
Speaker 3: seeing that youI preview and getting your documentation all in
Speaker 3: one place. That is definitely I think the way to
Speaker 3: go if you're going to have a full on library
Speaker 3: in its own repo, if you're kind of starting off
Speaker 3: a little bit more basic, like we're just going to
Speaker 3: have this shared folder, then I think it's okay to
Speaker 3: also not be swayed by all the bells and whistles
Speaker 3: of stuff like Storybook. Again, the more important part is
Speaker 3: you get it out there, get it used. Once you
Speaker 3: go down, once you go down the rabbit hole of
Speaker 3: looking for things that you can use in your component library,
Speaker 3: they're going to find a lot of great stuff, because
Speaker 3: there's a lot of great stuff out there in terms
Speaker 3: of right not just Storybook, but all the add ons
Speaker 3: that you can add to it, all the ways that
Speaker 3: you can customize it, whatever you want to use to output,
Speaker 3: or using roll up or using this, or what icon
Speaker 3: st are you using, And it can escalate so fast,
Speaker 3: and I think a lot of people get mired in
Speaker 3: that swamp of too many choices. My trademark that the
Speaker 3: swamp of too many choices. That's a legitimate thing for sure.
Speaker 2: You see, if that domain is available, that's what.
Speaker 3: I need another side project domain to sit.
Speaker 1: So, Catherine, how do you how do you deal with
Speaker 1: either requests like people need specific components that your team
Speaker 1: hasn't built, or you have an open source project and
Speaker 1: people are contributing, like how do you manage that part
Speaker 1: of it? And getting people to contribute and then helping
Speaker 1: manage the contributions to make sure that they, you know,
Speaker 1: meet the requirements and are going to be useful to
Speaker 1: more than just one person who built it, and stuff
Speaker 1: like that.
Speaker 3: I think in terms of getting people in it can help.
Speaker 3: Because I've been doing THEWS in a corporate setting and
Speaker 3: not in an open source setting, I have had the
Speaker 3: benefit of less optional participation. Maybe the nice way to
Speaker 3: say it, if you decide as a team that this
Speaker 3: is your goal, and you have whoever's leading the team
Speaker 3: on board with your idea, then it's just a project
Speaker 3: like any other project. It might not be everyone's favorite.
Speaker 3: I've built features that are not my favorite, and it's
Speaker 3: just part of your job. I think what's important is
Speaker 3: to not look at the component library. If you decide
Speaker 3: to do it, then it's not a side project. It's
Speaker 3: not an offshoot or a pie in the sky. One day,
Speaker 3: we'll get back around to this thing that you can
Speaker 3: keep back burnering. It's a project like everything else that
Speaker 3: you're running right now. It has a different user base,
Speaker 3: but it's a project all the same. And so I
Speaker 3: really advocate for building it into your sprints in the
Speaker 3: same way that you would build any normal project. Work,
Speaker 3: break it down, estimate it, throw it in the sprint,
Speaker 3: assign it to someone. It's just work. The fact that
Speaker 3: it's internal work shouldn't change that.
Speaker 1: You know.
Speaker 2: Yeah, I'm curious, do you're running too struggles where can
Speaker 2: totally see some project they need some new component and
Speaker 2: the quote unquote right way to do it would be
Speaker 2: to build it into the component library. But the faster
Speaker 2: way to do it, whether it's for deadlines or for
Speaker 2: whatever reason, is just to like, let's just toss it
Speaker 2: in there and go with it. Do you find you
Speaker 2: run into that struggle a lot sometimes?
Speaker 3: And I think it is also okay to just throw
Speaker 3: it into the app and circle back to it. You
Speaker 3: just need to document that, and again that needs to
Speaker 3: be its own story that comes up in your next sprint,
Speaker 3: and you can't.
Speaker 1: Back burner it forever.
Speaker 3: If it really is like we have to get this
Speaker 3: out build it, you can always come back and pull
Speaker 3: it out into the library later and refactor. But usually
Speaker 3: the idea that you're giving your future self more work
Speaker 3: is enough to dissuade folks from doing it that way,
Speaker 3: unless it's a real emergency, because who likes to do
Speaker 3: Probably some people, not me. But I think the better way,
Speaker 3: the ideal way to handle that is to actually just
Speaker 3: estimate that story component building work.
Speaker 1: Sorry, won't try it again.
Speaker 3: The better way to do that is to just estimate
Speaker 3: that component work into the larger story. So if you're
Speaker 3: saying we need to build this feature, and we know
Speaker 3: this feature will include a component that should realistically be
Speaker 3: in our library, then building that component putting it in
Speaker 3: the library is part of building that feature, and so
Speaker 3: when you look at it, you don't say, like, well,
Speaker 3: you might have to add a couple of points to
Speaker 3: get the component library work accounted for. But the other
Speaker 3: truth is that once you've got your component library up
Speaker 3: and going, the overhead of adding new components and putting
Speaker 3: them into the application is really really small. You're building
Speaker 3: it in the same way you were going to have
Speaker 3: to build the future anyway, you're just building it a
Speaker 3: different repo and adding an import statement. Better to I think,
Speaker 3: knock it out than give yourself work down the road.
Speaker 3: Doesn't save you as much time as you think it would.
Speaker 1: Oh boy, I can totally agree with that. There have
Speaker 1: been many times when we should have done it in
Speaker 1: a better way that we didn't, either because the requirements
Speaker 1: changed further down the road and we didn't know that's
Speaker 1: what was coming up, or like you said, because we
Speaker 1: needed to get it done in time of sprint. But
Speaker 1: that's a great segue. I was wondering how you handle
Speaker 1: documentation because that's something that my team has always struggled with,
Speaker 1: and we're not building a component library, So how do
Speaker 1: you document something beyond Storybook? Because I know it has
Speaker 1: a lot of great interactivity, so that other developers on
Speaker 1: other teams can use it and understand what the components
Speaker 1: can do for them. I would actually say that that
Speaker 1: is a part of Storybook. They've got a whole kind
Speaker 1: of feature set devoted to writing documentation and showing examples,
Speaker 1: and it's pretty much up to you how much you
Speaker 1: take advantage of that storybook will automatically generate documentation, but
Speaker 1: realistically that's not going to be what you want. It's
Speaker 1: just going to give you kind of an output. It'll
Speaker 1: show you the component and the props that are passed in.
Speaker 1: Can I give you the controls so that you can
Speaker 1: see like, oh when it changes? That change? Is that?
Speaker 3: But the kind of documentation that you need in addition
Speaker 3: to that straightforward technical documentation is the design and UX documentation.
Speaker 3: So you've got three different buttons. How do you know
Speaker 3: when you're supposed to use this primary one as supposed
Speaker 3: to the secondary one? How do you know when I
Speaker 3: need this header as opposed to a subheader or whatever?
Speaker 3: All those those contextual pieces are just as, if not
Speaker 3: possibly more important than the technical documentation, which is pretty
Speaker 3: easy to write honestly, right if you're checking your prop
Speaker 3: types and you're defining things well as you're writing them,
Speaker 3: then generally the technical documentation is minor and it's more
Speaker 3: the design documentation that's going to take the heavier lift.
Speaker 3: And it's one of those things that I feel is
Speaker 3: not fun, but it's just part of making the component
Speaker 3: in the same way that like maybe you don't enjoy
Speaker 3: writing tests or maybe don't enjoy, you know, going back
Speaker 3: and cleaning up your code after you've got something working.
Speaker 1: But it's just part of.
Speaker 3: Good hygiene, I guess, good code hygiene, making sure that
Speaker 3: you're not just coding to get something done, you're coding
Speaker 3: for the developer after you.
Speaker 2: With that in mind, when you so, I like the
Speaker 2: bit you said about the contextual the UX sort of background.
Speaker 2: So do you have like do you work with other
Speaker 2: design like UX people to sort of create these components
Speaker 2: and do those sorts of roles actually get involved with
Speaker 2: some of the documentation and such as well in terms
Speaker 2: of how these things are going to be used.
Speaker 3: Yeah, I've kind of been in both situations. In one case,
Speaker 3: I was the loan design person on the team, so
Speaker 3: I got a little bit of free reign, maybe for
Speaker 3: better or for worse, in terms of getting able to
Speaker 3: establish and build those things on my own. In my
Speaker 3: current position, I'm lucky to be working in a team
Speaker 3: that has multiple other designers in it, so we get
Speaker 3: the chance to bounce those ideas back and forth off
Speaker 3: of each other and really collaborate on making these kinds
Speaker 3: of components, which is a nice place to be, so, yes,
Speaker 3: I do think that that's part of the documentation. The
Speaker 3: way it works currently, we have a designer who's really
Speaker 3: focused on putting together a design system, which we're building
Speaker 3: at the same time as our component library, because you know,
Speaker 3: we like to be ambitious, I guess. So she'll go
Speaker 3: through and kind of take a look at the design
Speaker 3: side of components and say where they should be used
Speaker 3: and when they should be used, any kind of guidelines
Speaker 3: in terms of something like the amount of copy that
Speaker 3: should go into a tool tip, or kinds of options
Speaker 3: that we should present to a user if we're giving
Speaker 3: them choices in a pop up model or something. Those
Speaker 3: kinds of design decisions that can be a little harder
Speaker 3: to make from a technical perspective, So she'll kind of
Speaker 3: go through and outline those aspects and she usually just
Speaker 3: includes them as maybe comments or lines in the PIGMA file.
Speaker 3: And then we have a couple of folks who we
Speaker 3: call ux engineers, which are kind of like me that
Speaker 3: get to have a foot in each world and we
Speaker 3: kind of get to be that bridge and look at
Speaker 3: those components and say, all right, we'll build it in
Speaker 3: this way. Because she only wants, you know, a max
Speaker 3: of this many characters. We can prevent that, you know,
Speaker 3: we can set guidelines and kind of blockers in the
Speaker 3: way that we build the component that prevent it from
Speaker 3: being used in a way that it's not intended. You know,
Speaker 3: we can have inputs get validated and things that prevent
Speaker 3: you from just blowing through. Even if you opt not
Speaker 3: to read the documentation, which hopefully you do.
Speaker 1: Documentation is tempting. That's usually where I'll go. Well, I
Speaker 1: shouldn't say that I go there pretty quickly, but it
Speaker 1: really depends. But that's really cool that you get to
Speaker 1: kind of be a little bit of both both the
Speaker 1: designer side and the actual engineering side. Have you always
Speaker 1: been in a role where you kind of get to
Speaker 1: span both or has it kind of progressed since as
Speaker 1: you've been doing development.
Speaker 3: I feel very lucky to be in a space where
Speaker 3: I get to do both. Actually, and it honestly came
Speaker 3: from the other side. I started off in the design world.
Speaker 3: That's actually what I went to school for. I have
Speaker 3: a fine arts degree, which you know has helped me
Speaker 3: tons I say sarcastically, but in all sincerity, it really has,
Speaker 3: and that it's given me that I for color and
Speaker 3: design and hierarchy and balance and flow and that kind
Speaker 3: of edge when it comes to working with clients and
Speaker 3: understanding what a user wants and what someone's looking for
Speaker 3: and how to kind of give it to them in
Speaker 3: a way that will be intuitive and satisfying and hopefully
Speaker 3: enjoyable to use. So I started off on that end
Speaker 3: and have actually been slowly making my way into development because,
Speaker 3: as it turns out, it's just more fun.
Speaker 1: I completely agree with you. It is more fun to
Speaker 1: be built, and in your case, designing it as well.
Speaker 1: That's I think that's such a useful skill to have, honestly,
Speaker 1: and I wish I had more of a design background
Speaker 1: because I feel like it would help my own side
Speaker 1: projects turn out a lot better than they probably currently are.
Speaker 3: I firmly believe that it's a skill that anyone can learn,
Speaker 3: like anything else. I think, especially in the arts, we're
Speaker 3: quick to look at something and say, but you just
Speaker 3: have to have the eye or have some kind of
Speaker 3: innate talent, And I think that's a good starting point.
Speaker 3: Some people absolutely do, and they'll have that level of
Speaker 3: native talent just kind of automatically. But the same is
Speaker 3: true for development. Some people have a really amazing kind
Speaker 3: of logical mind that can break things down and can
Speaker 3: see the kind of pathways and relations between these components.
Speaker 3: They can see the way things get passed through functions
Speaker 3: and how things will return. I don't have that, but
Speaker 3: it's a skill that I've been able to cultivate just
Speaker 3: through doing it and hard work and messing up the
Speaker 3: But I believe there are versus is true as well
Speaker 3: that if design is something that developers are interested in,
Speaker 3: then absolutely there are places you can start in skill
Speaker 3: sets you can learn and it benefits your work at
Speaker 3: the end of the day.
Speaker 2: Yeah, I think it's sort of akin to like the
Speaker 2: closest example I can think of is like sports, Like
Speaker 2: there's some people that naturally and I see this with
Speaker 2: my kids, right, certain people just pick up on things
Speaker 2: faster than others. You throw them a ball, they know
Speaker 2: what to do a little bit better. But anybody can
Speaker 2: learn it, right, Like, it's just a matter of you
Speaker 2: have to actually put in the time. You can't And
Speaker 2: I'm guilty of this too. You dismiss it of like
Speaker 2: I could never draw anything, so I'm not even going
Speaker 2: to try sort of thing. Like I said, it's totally
Speaker 2: a sentiment I'm guilty of too, But it's totally easy
Speaker 2: to have that gut reaction. It's far harder to actually
Speaker 2: put in the time and the effort to try to
Speaker 2: learn a skill yourself.
Speaker 3: Absolutely definitely, I'm in that same camp of like, I'm
Speaker 3: honestly not a great drawer. My pen and paper skills
Speaker 3: are are lacking. I suffered through a couple painting and
Speaker 3: similar courses in college so that I can get to
Speaker 3: the design classes I was interested in, and I don't
Speaker 3: feel that that in my lack of ability to draw
Speaker 3: much more than a stick figure has actually impeded me much.
Speaker 2: So I do have one question to bring it back
Speaker 2: to the component library a little bit. I'm curious how
Speaker 2: you handle, say, like more complex components, right, because I imagine,
Speaker 2: so you build a button, you build some of these
Speaker 2: things like those are something like any web developer can
Speaker 2: do pretty decently, but I imagine there's a complexity level
Speaker 2: where you're probably not going to write it sort of
Speaker 2: yourself from scratch, Like I'm thinking like day picker, Like
Speaker 2: you can even go crazier than that, right, you can
Speaker 2: go into like charts and graphs and grids, and it's
Speaker 2: all yeah, tables exactly. So I'm curious if there's a
Speaker 2: line where like you would say like, Okay, this is
Speaker 2: too complex, and then at that point, would you like
Speaker 2: wrap some other library out there and sort of like
Speaker 2: Chris and that is like this is the standard solution
Speaker 2: we use for this or would you just leave that
Speaker 2: up to like individual apps. I'm curious how you'd handle
Speaker 2: that sort of scenario.
Speaker 1: Yeah, I think it really needs to be kind of
Speaker 1: a breakdown of what again, what you need that might
Speaker 1: be different. I think there's no value in reinventing the wheel.
Speaker 1: You know, D three is a great library that exists
Speaker 1: for charting. There's no need to remake D three in
Speaker 1: your component library, right.
Speaker 3: And I also think it's totally fair game to import
Speaker 3: it into your library and customize the bits that you
Speaker 3: need and make sure that it's only being used in
Speaker 3: specific ways that reflect the needs of your application, right.
Speaker 3: And I think that can even be really helpful rather
Speaker 3: than just giving someone free ran Like we use this
Speaker 3: charting library, here's twenty million charts that you can choose from,
Speaker 3: twenty million different ways that you can present the same data.
Speaker 3: The component library can help you narrow that down. Okay,
Speaker 3: in this case, we use a barograph. In this case
Speaker 3: we use a high chart, and it kind of removes
Speaker 3: that mental lift I guess, which would really be.
Speaker 1: Tangent.
Speaker 3: I think that would really be the primary benefit of
Speaker 3: a component library if I had to, like really sum
Speaker 3: it up, give you the elevator pitch on why you
Speaker 3: should make one. It's that it removes so much of
Speaker 3: that design decision making fatigue that you do over and
Speaker 3: over in terms of do I need this, does it
Speaker 3: need to look this way? What styles does it need?
Speaker 3: What's the best solution for this?
Speaker 1: You can make that decision once and then pull that
Speaker 1: component over and over and over again and know that
Speaker 1: it's been thoughtfully created and I can just trust that
Speaker 1: it's the right choice.
Speaker 2: That's a good point, because it's you just tell a
Speaker 2: bunch of people, yeah, go google react chart and see
Speaker 2: what happens. Right, You're gonna everybody's going to come back
Speaker 2: with wildly different ideas of what to do, and you'll
Speaker 2: end up with the same situation as the header. Right,
Speaker 2: everybody's got different ideas for what's best and what we're using,
Speaker 2: and it'll be chaos.
Speaker 3: Yep, No, there's just as much value in my last place.
Speaker 3: We had no real illustrator on the team and no
Speaker 3: real person whose passion was making icons. So we chose
Speaker 3: an icon SPT and we built it.
Speaker 1: Into a component library, and you said, this is what
Speaker 1: we use if you're building components, if you're using it elsewhere,
Speaker 1: we use in that case found awesome, you know, and
Speaker 1: that that narrows down that feeling of I need to
Speaker 1: go find something, or having icons from twenty different sets
Speaker 1: scattered across the application. Yeah, it's done. You don't have
Speaker 1: to think about it.
Speaker 2: If taking that approach, do you run into any issues
Speaker 2: like getting dependencies to match up? Like so I'm imagining
Speaker 2: you have like five apps using your component library, right
Speaker 2: and you're like, oh, app one needs a new version
Speaker 2: of found awesome. Then does that sort of imply then
Speaker 2: the net So then the other four apps right when
Speaker 2: they go upgrade, they're going to need to pick up
Speaker 2: the new version has And I could see that going
Speaker 2: both ways. That's kind of curious, Like I could see
Speaker 2: that being like a forcing function of keeping people up
Speaker 2: to data and dependencies, but I could also see it
Speaker 2: being like a blocker, like oh, we need to update something,
Speaker 2: but we don't want to have to test the new fun,
Speaker 2: awesome version for everything too, So I'm curious what your
Speaker 2: experience has been with that.
Speaker 3: Yeah, it can definitely be a little bit of a roadblocker.
Speaker 3: I'm maybe lucky that I haven't quite been in a
Speaker 3: situation where I have to manage five I think that
Speaker 3: most have done is two or three different applications playing
Speaker 3: from the same component library, and it was a real
Speaker 3: motivator for us to keep everything as up to date
Speaker 3: as possible. But it did also mean that there were
Speaker 3: some things that we didn't update in the library because
Speaker 3: we didn't want to mess things up in the application,
Speaker 3: and there was a little bit I think it's honestly
Speaker 3: just the same way that you judge whether you need
Speaker 3: the update in the application itself. You look at it
Speaker 3: and you say, what does it offer for other features
Speaker 3: that are in this release that are really important for us,
Speaker 3: that make the effort of jumping up a version or
Speaker 3: you know, five or ten worth it. And eventually you
Speaker 3: get to the point where you need to and it's important,
Speaker 3: and you make the time and you make it happen.
Speaker 3: But it's really just a question of version management in
Speaker 3: the same way that you version manage every other dependency.
Speaker 3: I think in your app. It just kind of has
Speaker 3: that trickle down effect. Like you've talked about, you're really
Speaker 3: doing version management in two apps. But I think the
Speaker 3: decision making progress process in terms of when do I
Speaker 3: do it, is it worth it, it's more or less
Speaker 3: the same. So you've talked about some really interesting stuff
Speaker 3: that you're doing at work. Is there anything that you're
Speaker 3: working on on the side that is equally exciting to you?
Speaker 3: I find equally exciting if anyone else of actually in
Speaker 3: the process of building a web application called bubble up
Speaker 3: that's intended to help COVID nineteen social bubbles coordinate their
Speaker 3: kind of activities and share information with each other. So
Speaker 3: the hope is that you know, in an ideal situation,
Speaker 3: you say that people in your bubble or your pod
Speaker 3: or your quarantine, whatever you're calling it, don't ever interact
Speaker 3: with people outside of that, But the reality of that
Speaker 3: is much more complicated, and that there will always be
Speaker 3: exceptions that come up, and rather than pretending they don't happen,
Speaker 3: I'd love to be able to build those into the
Speaker 3: planning process as a realistic way for people to still
Speaker 3: be able to meet up and do so safely, and
Speaker 3: do so honestly and kind of put all of that
Speaker 3: communication into one hub. So that's my current that's my
Speaker 3: current work in progress. I'm hoping for an end of
Speaker 3: year launch on that.
Speaker 1: So is there like beta test going on right now
Speaker 1: or are you looking for help? Like as an open
Speaker 1: source type of project, it's currently a bit of a
Speaker 1: one man show. I am definitely open to folks that
Speaker 1: would like to help if they're interested. I have a
Speaker 1: user survey up right now, trying to get a feel
Speaker 1: for what features are important to people, making sure that
Speaker 1: we prioritize development in that way. You can find that
Speaker 1: at bubbleupapp dot com. It's also wait list, a mailing
Speaker 1: list that you can join, and we'll keep folks informed
Speaker 1: when we are ready to start doing some beta testing,
Speaker 1: when we're ready to start doing some some just kind
Speaker 1: of general user click testing. The UX person and me
Speaker 1: won't launch an app without that, and of course when
Speaker 1: we release properly, that's awesome. That's such a I mean,
Speaker 1: not only such a good side project to learn in,
Speaker 1: but also such a potentially useful one. Are you are
Speaker 1: you building it with React? I am building it and
Speaker 1: React The major question. No, I'm definitely the job I'm
Speaker 1: in now is an Angular, but I think my heart
Speaker 1: will always be with React personally. I started off an
Speaker 1: Angular and I am much happier building almost exclusively and React.
Speaker 3: So I feel you, at the end of the day,
Speaker 3: they're all just tools in the toolbox, but I think
Speaker 3: it's also totally fair to have favorites.
Speaker 2: Curious too, do you find like the React to me
Speaker 2: like because you build component libraries in both as well? Right,
Speaker 2: are there any differences like specific to component building that
Speaker 2: make you prefer one or the other.
Speaker 1: Hmm, that's interesting. I'm not sure. Trying to think through
Speaker 1: React seems a little bit more intrinsically built to kind
Speaker 1: of handle that component style breakdown. Angular does too, so
Speaker 1: it's definitely not, you know, a roadblock, But I think
Speaker 1: the way in which you kind of learn React and
Speaker 1: things are, at least the way I was taught to
Speaker 1: kind of break things down into components and components really
Speaker 1: modular is a really good fit. I'll also say that
Speaker 1: a lot because React is is UI focused and not
Speaker 1: you know, full framework no way that Angler is, it
Speaker 1: can be a little simpler. You kind of have narrowed
Speaker 1: your focus a little bit, and a lot of the
Speaker 1: tools that are out there for building component libraries tend
Speaker 1: to be a little more React focused. I've run into
Speaker 1: that a little bit with Storybook, which again is great,
Speaker 1: I've used it for both, but a lot of the documentation,
Speaker 1: a lot of the examples are going to be targeted
Speaker 1: towards folks coding and React. There's been a little bit
Speaker 1: of a bumpy road to kind of figure out how
Speaker 1: exactly that translates. Well, Catherine, it's been a pleasure talking
Speaker 1: to you. Is is there anything that we have not
Speaker 1: talked about that you think that we should I don't
Speaker 1: think so.
Speaker 3: Trying to like, I mean, I've pulled up the discussion
Speaker 3: points and noother thing.
Speaker 1: It's like, was there anything? I don't think so.
Speaker 3: I feel like I could talk about component libraries for hours,
Speaker 3: but I doubt.
Speaker 1: That's what you want. So no, I think this has
Speaker 1: really been interesting. That kind of makes me want to
Speaker 1: revisit my own team's decision to use AUNT. But oh man,
Speaker 1: we're already really committed to it, So I probably shouldn't
Speaker 1: open that can of worms. I don't know. It's a
Speaker 1: fun can. So if people want to get in touch
Speaker 1: with you or learn more about you, how where can
Speaker 1: they find you. You can visit my personal website, Kagreyson
Speaker 1: dot com. I'm also on Twitter perhaps too. On Twitter
Speaker 1: also at Captain Grayson. Was there probably the best race? Awesome? Okay,
Speaker 1: so now it's time to move into our picks for
Speaker 1: the show, and this is when we talk about cool websites.
Speaker 1: We've found things, we've been using, TV shows we've been watching,
Speaker 1: really anything. So TJ, would you like to start us
Speaker 1: off this week? Sure?
Speaker 2: So I've been I've an app recommended to me called Strava.
Speaker 2: I don't know if either of you've heard this before,
Speaker 2: but it's it's almost like almost like a social network
Speaker 2: for exercise things like runs and bikes and stuff like that.
Speaker 2: And I'm far from like an elite athletes, Like I
Speaker 2: get my bike out twice a week so and I
Speaker 2: consider that a victory. But the kind of fun thing
Speaker 2: I found about it is since it encourages like social stuff,
Speaker 2: it's a way of me keeping up with people that
Speaker 2: I don't see in my life anymore, right, like coworkers
Speaker 2: that I'm not seeing. It's just like another way and
Speaker 2: it's outside of like you know, as discussed like I'm
Speaker 2: sometimes too much on Twitter also and it's kind of
Speaker 2: fun to just take that out of the equation and
Speaker 2: just have a fun little thing to see what your
Speaker 2: friends are up to.
Speaker 1: So that's my pick. Very cool. That sounds like a
Speaker 1: great way to stay more active, too, which is something
Speaker 1: I've definitely been struggling with since the pandemic and my
Speaker 1: gym shut down and that I didn't feel comfortable going
Speaker 1: back to the gym after that, so that's good. My
Speaker 1: pick today will be a standing desk that I just
Speaker 1: bought last weekend and am very already very excited about.
Speaker 1: It's called the Tresante or Trasanti, and it is from Costco,
Speaker 1: although I believe that you can buy it on Amazon
Speaker 1: and possibly Wayfair also. But it is an adjustable height desk.
Speaker 1: It is a powered one, so you just it's got
Speaker 1: like three different settings that you can pre set for
Speaker 1: you know, however, whatever your preferred height of working is.
Speaker 1: It's been really really cool so far, and it's it
Speaker 1: was only three hundred dollars, which is way less expensive
Speaker 1: than most of the other powered or unpowered desks I've seen,
Speaker 1: so I am a big fan of it and I
Speaker 1: would highly recommend it. It's not too large, it's not
Speaker 1: too small. It's pretty great. I would definitely recommend checking
Speaker 1: it out if you have a cost co membership and
Speaker 1: you need like a real space, because up until this
Speaker 1: point I was working at the dining room table, and
Speaker 1: after seven months of that, it seemed like it was
Speaker 1: probably an investment worth my tie. So that's going to
Speaker 1: be my pick for today. Catherine, do you have any picks?
Speaker 1: I know this is a little last minute for you.
Speaker 3: My pick would be Notion, which is probably a familiar
Speaker 3: platform for some folks, but just in case, through one
Speaker 3: of the two people that have never heard of it.
Speaker 3: As someone who is currently managing my own personal life
Speaker 3: and building an app and building a component library twenty
Speaker 3: million other things, I've created Notion databases for all of those,
Speaker 3: and I feel like I'm pretty much living out of
Speaker 3: that app now. I've got, yeah, one for the app
Speaker 3: and one for like family recipes that we're all sharing,
Speaker 3: and one for just personal things to do list my calendar.
Speaker 3: I feel like if if I didn't have somewhere, I
Speaker 3: could doulp my brain lose all of that. Notion has
Speaker 3: been just a lifesaver in that regard.
Speaker 2: I'm one of the two people that hadn't heard of it,
Speaker 2: so maybe the other person is listening here. I'll have
Speaker 2: to check this out because I'm currently my life revolves
Speaker 2: around one single text file that I keep on my laptop,
Speaker 2: which I mean works better than you might think, but
Speaker 2: it doesn't scale the greatest.
Speaker 1: Going to say that just gave me a little bit
Speaker 1: of anxiety.
Speaker 2: Mary about It's okay. I have sections to it like.
Speaker 2: It's not pure chaos.
Speaker 1: Mine's more of the disorganized. I have some notes on
Speaker 1: my phone, I have some notes on my laptop. I've
Speaker 1: got a Google doc, I've got Google Keep, I've got
Speaker 1: stuff everywhere, but no centralized system for where anything goes.
Speaker 3: Really can I make a second pick? Actually, because that
Speaker 3: propped it us. Yeah. Something I recently picked up is
Speaker 3: a product called Rocketbook, and it's basically a reusable notebook
Speaker 3: and you can troll on it.
Speaker 1: You've got special pens. It actually feels a lot like
Speaker 1: paper versus some of the ones that feel like dryaries.
Speaker 1: But the cool part is it's got an app with it,
Speaker 1: and it comes with like a little QR code in
Speaker 1: the bottom of corner and it'll scan it and automatically
Speaker 1: upload to wherever you have set things to go. Some
Speaker 1: mine go to like my dropbox. It's been really great
Speaker 1: for wire framing, especially which I like to do on
Speaker 1: paper because I don't know evidently eighty so I like
Speaker 1: to draw anything out on paper freation and then upload
Speaker 1: it and then I'll have to sit and you know,
Speaker 1: actually make a real wireframe out of it and design software.
Speaker 1: And being able to skip that like awkward scanning or
Speaker 1: like photo taking with my iPhone face of it has
Speaker 1: been super nice. No, that's awesome. I'll have to check
Speaker 1: that out because I'm kind of the same as you.
Speaker 1: If I am trying to design something, I just really
Speaker 1: like to do it on a piece of scratch paper
Speaker 1: and then yeah, I'll end up hauling that around with
Speaker 1: me everywhere until I've finally gotten it designed.
Speaker 2: I'm sort of fascinated by this. I'm just looking at
Speaker 2: the pictures and videos of it on the site. It
Speaker 2: amazes me how far the technology for this has come.
Speaker 2: Like even like back in our office, back when offices
Speaker 2: where a thing like we had some stuff like similar
Speaker 2: not quite like this, but like a whiteboard that was
Speaker 2: like you said, it's not like technologies come beyond dry erase,
Speaker 2: which sort of fascinates me, Like there's stuff that actually
Speaker 2: like comes off and doesn't leave marks till the end
Speaker 2: of time. So it's kind of cool that I didn't
Speaker 2: realize you could get this in a book that's like
Speaker 2: individual thing you can take around with you.
Speaker 1: Yeah, jig, but it's like my poor man's iPad. I
Speaker 1: could probably accomplish similar with like an iPad and apple pencil,
Speaker 1: but this was, you know, a couple hundred dollars cheaper.
Speaker 1: It seems like it'd be a lot less distracting as well,
Speaker 1: because the iPad is as bad as my phone. Honestly,
Speaker 1: that's true. And you do get that feeling of drawing
Speaker 1: on paper instead of drying on a screen, which, again,
Speaker 1: I know I sound like very old fashioned, but it
Speaker 1: does make a difference I think totally. Well, Catherine, thanks
Speaker 1: again for having us on. It's been a real pleasure
Speaker 1: to talk to you today. Thanks very much for inviting me.
Speaker 1: Had a great time. Alrighty, so we've talked about how
Speaker 1: to get in touch with you, so I guess we
Speaker 1: will see everybody on the next episode of React Round Up.