GitLab Digital Experience, 24 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Digital Experience Retro Video - Feb 24, 2022

Description

Digital Experience Handbook Page: https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/

A

Hi everyone uh welcome to the digital experience team uh retro, iteration retro today is thursday february 24th uh we'll go over some of the things that went well and things to improve on uh from this last iteration uh for things that went well. First up is jess carrie started and we're super stoked about it and she's fully onboarded, so she's actually doing design work now, which is awesome, and our design team is back up to three, which is great happy to have you.

B

And next is me: I had a very cool pair programming session with javi. We got lots of things done both on his side and my side, so very productive nice to have those.

C

Yeah, I added a note just that, like I, I want us to make some form of structure for us to like be able to like ask and receive help for stuff like this, because I feel, like you know, when we're blocked, it's helpful to have someone to like go in and do stuff and then other times when people have capacity to do things anyway.

D

A

Cool we can jump into things to improve on uh barker. Has the first point.

E

Yeah um something that they do over in the product- and I think we should do here is you know, don't assign an mr um a reviewer until it is ready to go code is good review. Apps passing draft is removed. Description says what changed. Why all the stuff? um Because for me, once I see the to-do mark like come up, then I instantly go, look at it and then, if I see it's not ready, I'm like ah and then I have to come back to it and you know that can cause the delay.

F

um Now this was kind of mentioned last week in the last retro, but there's just quite a bit of regressions that come through affects a lot this week and I think a lot of this could be solved if folks just take due diligence like if you touch a shared component, maybe just check pages that use that same component. I know tyler mentioned here. I was gonna, bring this up too. If you're using vs code, you can search uh like within files.

F

What I like to do is if you're touching, like the copy view component um search for that and see what pages are consuming that as well and just give them a give them a look in your local or the review app. I think it can save a lot of time. um Tyler did you want to speak to more of your points.

D

Yeah, I have a lot here because I think that this is like the primary challenge that like collaborative teams face in web development, um and I think that there are like established ways to solve it uh and so uh yeah. I mean the first thing quick to like. We could change no processes and everyone could do an extra step of work, which is just command shift, command, shift f in vs code and just like look for all the references and then go look at them um and see what broke.

D

And what didn't um that is like the quick and dirty way to just like not like. It requires no changes in our workflow other than people. Do that extra step. But uh I don't think it's sustainable, because if you have 80 pages like then you have to check all 80 pages, um and since we offer regression tests set up and like and we shouldn't, I still contend because we're not there yet like it's just like that's, not a sustainable way to do it, um the more sustainable way to do it.

D

I I think there are two two paths: um one we have tried in the past and, like also didn't, I don't think shook out, is sustainable for this team, but, like maybe it's different now I mean like truthfully. We could all just write our own components like we don't have to have any shared components. um I don't know like. I know that that's like I know a lot of people are really all about like drying up code, but like like, like I don't care personally like it might like, like copy paste, is totally fine.

D

It's you know a tried and true method and like maybe we don't need to dry things up until we're like really sold on how stuff works, um but we that was my approach with like the first iteration of slippers, and I don't think that, like that, I think people had other challenges with it and didn't like it. So I'm not advocating for that um or I am advocating for it, but like not strongly because I don't think it will fly. um Here's the other approach- and this is what I actually wrote in the minutes.

D

um I think this should work and is like really important and there's like two fundamental pieces of it so like if there's a shared component, and it must change here- there is, I think, a there are two heuristics that you can use to determine. Should I change this shared component, or should I make a new one? Even if you want to make a new shared component? um The first is: can I augment this with a single literal value prop right, so a good example would be text. Alignment left center right.

D

So if you have a thing that, if you have like a paragraph component and you want to change the alignment of the text like, can you pass a single prop to it that says, left center right and accomplish your goal? If the answer to that is yes, then you should add the prop. You should also add a default value for them.

D

So if you make the prop optional in view and then add a default prop to it like keep the default prop, how it is now and then nothing else will break or change and then, in your use case like augment, like use the augmented value right, um so that's the first way is is using props. I think, if, like one prop with an object with a with a literal value, not an object.

D

um If that is sufficient to describe the differentiation, then you should do that and like don't worry about making a new component, the other heuristic you can use that is similar. Is you know when we think about front-end web development? We think about like the layers of html semantic markup css as style directions.

D

Javascript is interactivity like the foundation, is the semantic markup with html right, and so, if your augmentation to a component requires you to change the semantics by more than one degree and what I mean is like you might have a component that has an image and text, and maybe sometimes you don't want an image right. I think that's, basically conceptually that is the same component.

D

It is, you know, an image text component with or without image, but if your component requires two semantic changes that it is like now, an image it's either the image is toggleable or it's a paragraph or it's a list item all of a sudden, you're two degrees out in the semantics, and I think that we have lost the conceptual cohesion of that component and you should have two components: one that is a image and text.

D

So image tag, p tag where you can toggle the image on and off and another that is an image tag and like a ul tag where you can toggle the image off, and I think that conceptually the the single point of change for the semantics.

D

Once you go beyond a single point of change, I think that you're talking about a new component.

D

This is just an opinion like there's not like a technical reason like you could write a component that took every html element and made them all toggleable and it would be a hot mess right, but you could do it like it's not wrong to do it. There might be a use case where you're like this is a component that demonstrates how every single, like semantic element in html, looks in our in our styles. In our design system.

D

Right, like you, might actually have cause to have 150 different semantic elements in like one very niche scenario, but for like everything else. I think that if you are two semantic changes away, different component totally different component right, even if it's like very similar- and you can use it- and this is where I you know if nathan were on the call.

D

I think we could talk more about like slippers as the design system, because, like you know, if our design system is a bunch of the atoms of like the p tags and the lists and like the images and like that sort of stuff, then we can make these like higher order components like compose of those smaller pieces and I'm not sure what the direction is on slippers, because I have not worked on any of these code bases for the past six months.

D

So I've so like I'm just I'm coming in here with just opinions and like not rooted in like the work everyone else is doing, um but anyways, that's that's a lot. Those are my two heuristics. I think they work really well. um I think that the props is like the clever. It's like a clever trick for hey. I need to change this thing in this one instance, but I don't want to like break all the other alignments and stuff like use the default. That's why the default value well default value.

D

Is there for many reasons, but that's like one of the best uses of default values for props is like we make a change to a component that doesn't have to like go out and mess everything else up. It's basically a feature flag right and a lot, if you think about it that way, you're like getting it behind and you're making it opt-in right so like the behavior is not the behavior. It has now is default.

D

The augmented behavior is opt in and then, if you have to opt in to more than like one or two props and like barker asks this like like. When do you make a new version and that's where, like the semantics, come in or again like?

D

If you add more like this, is a number out of thin air more than two props is another component too right. Like same d, like I think that, like yeah sorry we'll go, um I think that the um I think you know. Fundamentally, the point is like if it is a variant of a thing, it should be like a small conceptual leap from this text is centered. It's left it's right. This image is on it's off right versus, like this is four different things that can be configured in actually 12 different ways.

D

I think that that you're talking about two or three components in that regard, so um that's everything uh I I know there's a lot.

E

I um have thoughts, um I I would say like like moving forward. We have a lot of global components um like the accordion benefits block, quote cards rapper carousel that copy component.

E

um As you know, if you're working with adding props to that component, you know maybe step back and like consider, should I just create a new component for this one, or should I extend this component for this particular use case um because we're having regressions because of it, which is okay, we're gonna, get regressions? It's not like it's gonna happen um and we have a great team that can help us fix them. Really quick.

G

I I also think that uh we have like uh components specific to some sections of the pages, so, for example, we have a cta for partners, a header that is different from the solutions one. So I think we we've kind of made that at until some point you know.

B

I also have a comment uh at what point: do we want to stop creating components in the buyer experience you can start creating them directly in slippers, because I think the goal of slippers is to have all the atoms there and just import in in the buyer, experience repo and not create new components. There.

E

I'd say once slippers is fully in and we're we're using all of the components that exist. Currently, um it's like the first step we gotta get to.

B

C

I would think that we would want to live in a future where we only create one offs within the buyer. Experience repository and anything that is shared across pages with live and slippers. But I don't know if people have opinions on that. That's right, that's what I think we may. We should move towards, but.

D

We should but like I think that it requires a really clear delineation of like what is a one-off component, because a lot of times we make a one-off component that then gets used three times right and like no.

D

I don't think I like, I don't think anything is ever a one-off component, because if it's like a valuable thing to build, we'll probably want to end multiple places right so like, even if we only have one cause to use it today tomorrow, we might want to put it in two or three places, and so I think, like the thing to do, I I think you're basically right, but I would like not call them one-offs because, like that, just no it's like saying that I'm building a prototype, it's like no one ever builds prototypes.

D

They all just become your production application um like. I think that, like at some point, we need to say this is where the design system and or this is where the ui kit ends. I know the design system is actually everything but like this is where the ui kit ends right. It ends with these atoms or these components.

D

Anything that is a composition of these, like building blocks, should be done in next right, like we should consume the library and compose and compose it, and then yeah, but like it's, I think, like the the challenge is that it is like a human decision and there is like not a technical like you could just put all of your components, slippers. We could just build every single one like there's, no technical reason we couldn't. So.

D

I think that, like at some point like um we just like someone needs to be, the decision maker I'm like here is how far the ui kit goes right and like and like these are the things that are in the package and then anything that requires more composition must be done in next um or or maybe we just make an even broader rule of like we never compose things in next next, like in nuxed, you always only consume from slippers and we build stuff.

D

We build compositional components in slip right like I, don't I don't think that's actually the right choice but like you, if you wanted to make it very straightforward and super simple, you could just say if you're in next you're, not writing, components, you're only writing pages right and if you're in slippers, you can write components. I don't think that's the right call, but it would be very easy to reason about.

C

Yeah something that we might consider as well as this has affected us in the past is like how this affects the rate of our development time to see, if like, if the decisions that we make affect us, because I feel like it has in the past, and so I just wanted to like yes and like yeah. I just want to throw that out.

A

There can keep talking at ui the code group and I think nathan is like hosting more front-end conversations also um so to be mindful of time. We'll keep moving yeah lots of lots of good question marks. um I think I think we're at tyler's point number three.

D

Yeah um this is, I think, everyone felt like our last release, video today and maybe last week, was like clunky like hard to manage because of all the screen sharing and the who goes next.

D

When um and like, I guess, my question is- and this is really to michael honestly because, like like one like, why are we doing release videos like what value do they give to the team, I'm not saying that they give none, but I I don't actually know precisely what it is, and I think michael is our biggest fan like he watches all of these so like. I would ask you, michael watching this now um or watching the release, video like what do you get out of them and like in order to serve that goal?

D

Do you need us to all screen share? Do you need us to even record those videos, or can you get the same value out of looking at the iterations? Now that we're using um no laura? I do not send those videos to my parents, that's the end of your sentence. I don't send.

D

I do not, um but yeah.

E

I would I would just.

D

Ask like what value do we get out of release videos we spend like half an hour every two weeks doing them and like um I don't just like it's a whole thing, uh maybe we don't need them or maybe we do need them, and if we need them, uh I would we should iterate on the format um I would advocate for just like not screen sharing ever because I think these videos are feel really great and natural and fluid we're all reading a document that we don't need to share on a screen because, like anyone watching it probably couldn't like read any like, I don't think that the the text would be super crisp.

D

um So yeah, I guess that's that's. My question is like what value and how can we make it better and also I propose we stop screen sharing during releases.

A

I had a follow-up point that might be moved, but um yeah. If you have nothing to show, then maybe that, like we shouldn't, be forcing ourselves to screen share if we're just gonna talk with our board up on the screen, you know, like that's, maybe not um useful if we are screen sharing. If we are continuing down this path of you know, demoing, visual stuff, that we've we've done that there's something to see I prefer to screen share myself, even though I was super slow at getting my screen going today.

A

um I prefer to do it myself, so I can show some of the cool things that I did. You know which um someone else might not know where those those tricks lie, but yeah yeah. I agree that finding out who watches and why and yeah that would help us make an informed decision.

D

Maybe screen sharing is opt-in right like like in any meeting like. Maybe we run it like a normal meeting that we record and we go through the list. Everyone talks about like stuff, that's useful to say and, like maybe you're like oh hey, like I want to show this thing, I'm really proud of it or like here's, this interesting bit of code or whatever to show but like personally, like.

D

I can't remember a time in the last six months where I've had visual stuff to show, and I always feel silly sharing my screen because I'm like here's the issues in mrs, like good luck, reading them in the 10 seconds. I talk about it.

B

Okay, so I have one final point that I think we can improve on the defaults that we are creating for our components, because in the remote case that the content is not there for a component, the page will just break because it's trying to read properties out of null because right now on the default for our components, we're mostly using null as a default for our data, which is where the content comes.

B

So I think maybe we should have. Each component have a default of an object that will at least render an empty component. Instead of just blowing up the page.

F

That's a great idea. Oh sorry, oh.

D

No sorry you're on the agenda go all.

F

Right um nathan had mentioned this, I think it was last week. Just um you know, we should be steering clear of adding like component configurations in the yaml file and okay. I don't really know the the best way to not do that with the amount of pages and stuff we're doing and making. But um you know it is getting pretty messy. It's like okay, this needs a border. This doesn't this needs a shadow. This doesn't like we're doing that in the yaml file, like one when it's not just us offering these pages anymore.

F

How are folks going to know what they should be, adding where they should be adding null um things like that, but this was a good point. Mateo.

D

Counterpoint, it's awesome when stuff breaks, because then you know that it's broken and if we add default, values that are technically valid but incorrect, I like is it possible that they leak out into production because everything built totally fine. You got no errors and you like forgot to swap in the actual content. um I don't know the use case like I just like, um because I imagine this is situational, but I think that there is a lot of value in breaking your pages when stuff is like.

D

Sometimes it is nice to have all of your stuff break really fast right like that, can be a useful tool in and of itself. um But I I have no strong opinion because I haven't ridden a component in a long time so, but just advocating for failing fast here.

B

That's just going to say uh for the case of these uh default props. They would not break on the pipeline. I think the earliest we would see it break other than local, of course, would be on the review app just saying it.

E

um Down the road we're going to implement a cms, we don't know which one and all of this styling done via the data. I don't think it's gonna play nice, so I think we gotta, we gotta, really separate the content from the design and the code. um We might have trouble later.

A

I think that's our last point sounds like we have lots to talk about in whatever meetings, ui code and whatnot cool. I will stop the recording there. Thank you, everyone for the good discussion.