GitLab Digital Experience, 12 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Digital Experience Retro - Jan 12, 2023

Description

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

A

Hi, everyone uh welcome to digital experiences, seller iteration retro meeting we'll go over some of the things that went well and things to improve on for the last two week period today is Thursday, January, 12th uh and first up for things that went well. uh Megan.

B

Yeah I just wanted to say thank you to Miguel who worked on the textbook issue for uh adding markdown like being able to use markdown in our storybook project, with our components, um just the thoroughness of it, and uh he took action to create like future issues, to actually complement it. It was just really well done and easy to read. So thanks again, uh anyone else before we move on all right, Nathan.

C

Thanks um yeah, just one thing, I noticed um like I, said: I originally wrote this data file for uh some of the comparison pages and I added in like a bunch of programming stuff like I, had Google analytics tags and, like all the static stuff, and then I realized that there was kind of this push that, um like that team wanted to edit those files frequently and I, realized that it was daunting because there was like hundreds of sometimes thousands of lines of crap in there, and it's not fair for them to have to go through it.

C

So I kind of realized that maybe we're targeting the wrong people and a lot of our yaml files like it's, not us it's kind of focusing on the contributor um and so that everybody can contribute, because it'd be amazing. If, if we didn't have to kind of click, accept on like every single content change- and that was just easy and we'd have to worry about critical things breaking.

C

If somebody were edit content, so um I just did a bit of a rewrite for some of the the comparison page stuff, but I'm wondering if we should do it for like pricing page or some of these other pages that are like super high traffic um and also maybe adding some sort of data, validation or yaml testing to be like, hey, like, for example, um the coverages In.

C

The comparison can only be like 0, 25, 50, 75 or 100, and so even small tests like enforcing that it's one of those values uh could save us a lot of time and headache. So, just like a thought that I've been going through I, don't know how to enforce this. uh It doesn't seem like the best way, obviously like a I, don't know CMS or like a database or an API display.

C

That would make more sense because you can enforce it easier, but yeah, just like a I'm trying to get the ball rolling, I guess I'm. Thinking about how our data is consumed.

D

Well and I'll type in like I also feel like. This is a good thing to think about like this next year, when we start the conversation of of an actual CMS for buyer's experience, understanding, like what's data and what's code, because they're kind of two separate things like or what's content.

D

What's code like some of the things or yaml files are great for us, but they're, not good for someone for any other user, and if we were to strip this out and put this into a CMS, the CMS doesn't need to have all of the like code, customizations built into the CMS, because that should be the content um person's job, just update content and we're updating the code like they didn't really have a good point and something we could think about.

D

Moving forward, how we can start start to separate, what's content and what's code somewhere, yaml files, it might help to them move forward when we jump into the CMS or dip our toes into the CMS. The future.

C

Do you want to voice that heavy I see typing away.

E

Oh yeah, uh something that Tyler did a while back for one of the pages was using interfaces to validate types. So essentially, if it's like, you define a data thing like a data schema so that, like you, have the different properties within it and if it's not of that certain type it'll just fail. The build of the site.

E

I thought that was something that was kind of cool. uh It's it shouldn't well, what I like about it is just that it's simple to do and it's like if something's like wrong, it'll, just build the air, the the site build, will air out, and so that's kind of like easy to find. If, like someone does something they're not supposed to it, doesn't push out anything. That's like say: a Content writer does something like for some reason, breaks the site.

E

It's like okay, like it gives us the ability to go in and be like all right like that should be fixed. I thought that was, that was smart, I'm, not sure how that works with their whole site, but I thought that was something that was really cool, that he did I.

C

Kind of like that in, like the next content module like throwing in an interface there when you make that request, so you kind of clean that data or review that data there huh I don't like that better than writing like separate tests, because they're gonna fail regardless so interesting, dang it Tyler why'd. You have to leave us hope, you're watching this. hmm Oh it's so good! Wait!

C

Oh I! Guess you could push it.

E

I'll link the thing that he did, let me find it and then I can add it to the dock, but we can do that. Async.

A

Are you our thoughts before I stop recording? Okay! Let me stop this now.