GitLab Digital Experience, 17 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Recap sprint 4 marketing design system

Description

Related OKR: https://gitlab.com/groups/gitlab-com/marketing/growth-marketing/-/epics/92

Inbound Marketing handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/

A

What's up everybody, uh this is digital experience, uh retro for the design system, team, um we're gonna be talking about our last uh two week: sprint uh and we're just gonna go over some of the docs that we've been kind of writing and ideating together. So some of our action items from last our last retro we're trying to just make sure that we are kind of following up with some of those we have file organization, as one and team feel free to stop me. If there's something in particular, you want to talk about.

B

We just um share the screen, so people can see.

A

Oh yeah, for sure, let me share it. Okay, do you all see this? Yes, okay, so file organization um decide on css framework, looking to discuss with stakeholders about no longer supporting ie, discussing research methods and meet with technical people to align.

A

uh I'm going to be talking about things that people thought went well, progress made in all directions. What feels like getting synced up as team slippers generates css file nbc3 of home page went, live looking much better, quick turnaround on improvements to the homepage. Ctas quick turnaround on the banner to bring back marketing announcements storybook until when css works smoothly and get lab.

A

Ui tailwind next.js works like a charm, some things that we want to improve on, and I think this is probably where we're spending a lot more time since there we want to have action items tied to some of the things that we want to improve on clean up branches.

A

um I think this is related to our repo health in general and there's a lot of branches that we don't know what they do in terms of things that people have pushed up, but we're not sure exactly if people are working on them, so just trying to maintain good repo health and this kind of falls in with this next point here, branding version best practices.

A

I think this is like a long conversation that we can have, but I think marketing in general, like the developers of marketing, want to make sure that we're all aligning on how to write styling so that, if I'm writing, styling or sammy is writing, styling or brandon. Is writing styling? It all feels like it's the same. I think that helps with outward communication so that people know what styling should look like on the site naming conventions.

A

We talked a little bit about this with steven as well, and we have some opinions on things that we could go, but this is like a much broader conversation and the the big thing is just making sure that we all have a shared language of what these things mean.

A

Personal habit of try, selectors attributes in alphabetical order, avoid numeric naming conventions, figma function with components aligning on what we want to do with accessibility is actually like a huge point that I think we need to define further more recognizable companies whose logos we can use for marketing working relationship with user research team and how to get more out of storybook html how to write markdown, docs and show the html, and what I mean by this is so that developers can see the actual component that's being rendered on the page and can just copy paste it into their into their own developer, environment, so action items.

A

I know that we we want to align on naming conventions as we've talked about, but in terms of the things to improve on is there?

A

Is there things that you all think that we have opportunities to grow in the next iteration, especially while people are away.

B

Maybe we just go through them one by one and see if there's an action item that we can take away.

A

Yeah, that sounds great.

A

So for this one for cleaning up branches, I'm going to follow up with brandon and chad.

C

Okay, yeah, I think, there's a script that we can run just to kind of you know maintain the repo health, like you were saying,.

A

It hasn't been.

C

A

Well, that was weird: did you see, okay anyway, I'll be awesome? Yeah.

D

So well, what about reducing the number fives under though.

C

So that's more of, I think, a long-term goal than an immediate action item um we could see. If there are any.

C

An action item could be to kind of analyze our lowest ranking pages that maybe don't get traffic or if there are any files that are unused.

C

But I'm not sure what the return at this point on is for doing that. So it may be a good idea to write up an issue just as as a shell issue for grooming that we can kind of see, someone do a you know a time-boxed analysis and uh you know see what they recommend. um I think would probably be the action item there.

C

Can you sum up, your action item really quickly sure sure um create an issue to research recommendations for reducing uh items uh files in the repo. I.

D

Guess we can arrange and sort files by the last access date if a file has not been accessed or accessed like three years done nobody's talking about that and no program is actually touching. That.

C

Yeah that'd be a good one too.

A

Yeah, something, I think would help is I don't know what text editor you all use, but for vs code you can kind of the search functionality for that is actually really smart, even if you don't aren't super familiar with, um like grip so like for regular expression searching. So I would think that's also a good way kind of to double check like where things are being used.

A

So, if something's not being used anywhere and we don't see any value to it, I think we can have the authority since yeah say like okay, like let's get rid of this.

C

E

C

And we already have kind of the naming convention stuff in there yeah create issue. That's good good action item there.

A

I love how all of these are just like, create an issue for this one specific thing, so that's great go ahead.

A

C

I I was, I was just going to say. uh I think it looks like the next item on the list. Maybe is the um oh aligning what we want for accessibility um that could be action. Item is uh well. I I think in the past we've discussed that kind of as uh like within well, so accessibility is done whenever we create each designing component and code, but it's also the the question of aligning on what we want for it.

C

um I'm not sure what the action item is there other than maybe to define uh in what ways we're trying to be accessible. I guess yeah, that's pretty.

D

Much really also things we need to cover on accessibility.

D

So if we can know these groups, then we can know if we are actually compliant or non-combined, then we can know what to improve if we are already doing good.

D

Yes, things like color contrast size of buttons for people who are fast fingers.

E

Yeah, I was going to say um with accessibility. It's there's often like a service level idea of what accessibility is, but when you actually go into it, there's a lot more nuanced approaches that we might have to adhere to um in terms of like how it replicates as well. It leverages on top of the product in terms of that type of accessibility, so there's obviously screen contrast and and general website accessibility, but then there's code, accessibility and then there's screen reader and things like that.

E

So it's actually quite a big task, but I think, if we're able to define that it helps us figure out what it is that we want to work towards.

A

Something that I thought about is we could just for the start of this if we could just copy what product uses for now and just like start there, that might not be a bad place to start.

C

Yeah, I think products has more resources and more optimistic goals. Then maybe we can achieve, but it's it's a good uh starting point. Like you said to kind of research, um I I like the mention of kind of the the service level uh agreement. Sort of you know, basically um what we aim to do whenever we're building each new thing. I guess, um and you know, maybe we get 80 coverage or 60 coverage. How do we measure that coverage? I guess so having a list where we can say we got to 80 of these things.

C

uh Next mvc will maybe be 100 or something like that. So.

B

Yeah um have some accessibility documents and checklists from uh like a two-day thing. We did at my last company with a accessibility like agency, so I can definitely share those out with you guys, and maybe we can use those as well as like a starting base.

D

Yeah, that would be great, and I have a couple of some documents like that too, because, like what stephen said, there's a lot in accessibility, for example, button rules and all that when you click it, but in the role of that button you need to define it what's the button intended to do maybe for someone using the screen reader if it's a pop-up, the pop-up needs to announce itself. But if you're not bothered about those demographics of users, then you are web accessible.

D

But if you need to satisfy those kind of users, then you are not accessible. So there is a little bit of weight balancing here and then that needs to be justified. So it's a lot, then you can.

A

Okay, more recognizable companies whose logos we can use for marketing.

B

Well, yeah that came for me, um brandon's, probably wearing this. uh We just the the logos that we have available for us to use right now are generally not like super well-known companies. I mean there's a few, but um I would love to know like who owns that space, so you can talk to them and see like if there's any other ones coming up. I had seen like um I don't know this public knowledge, but there was a large company who asked to use our logo, and so it was just like a slack thread.

B

I had happened to see like a few weeks back. Instead of they were like. Oh maybe we can use their logo in the future. So, like even asking like hey, is that a possibility now? Can we use? It would be great, but I don't know who like owns that.

A

B

To even ask the question.

A

Who do you think would be a good person to reach out for that team.

C

uh So I know there's a handbook documentation around it, but that doesn't mean it's necessarily up to date. We can check in with michael and becky, and probably someone in content, marketing and partnership or partner marketing. That might know those kinds of questions.

C

Do they have a slack channel, uh probably.

A

Okay, working relationship with the user research team.

B

It's also me, um as we may know, we've had a rough uh rocky road. So far um uh I don't know if we've like completely burned our bridges with them, but I also don't know what we could have done differently um to get the end result. So I'm just thinking more, like broadly, like we've been nice to maintain that relationship um and hopefully be able to work with them in the future. But right now it's it's not looking so good.

C

Yeah, I think, having followed the thread a bit, I would kind of phrase it as like. Basically, different teams focused on different goals focused on you know their their own product, we're on marketing. You know they have their processes in place. Maybe you know you know we reach out for help, and you know their timelines and methodologies might not match up with marketing best practices or methodologies. So it's it's kind of just it's not that we don't want to work with them. They don't want to work with us. It's just like we.

C

We have different priorities and goals at the moment, so um you know learning what we can from them and they'll. You know we'll share our learnings with them, one of the things that helped uh when we were growth, marketing team. uh We would share information with growth, product team and you know back and forth. So we formed a channel that we can. All you know, collaborate in and stuff like that, it's more of a long-term goal, but yeah. That's that's kind of my thoughts on that at the moment.

C

So maybe we can do something similar with.

A

Product ux research would it be a good idea to create a channel for something like that.

C

Yeah, I think that's definitely a possibility um or or even uh you know, maybe a working group like hey. You know we have this research project that we're working on. Do you have any recommendations, uh even though, following that um issue, there was a lot of back and forth already, but it's differently asynchronous to work in an issue versus having chats and slack and zoom and all that kind of stuff. So yeah.

A

I know it cut just off and she's the researcher.

C

A

So that's uh I.

B

Don't know I was just like nodding, my head in agreement: okay,.

A

I was like, let's not just, uh prescribe a solution for your problems that you deal so no.

B

I didn't really have any ideas, so I love it.

A

A

Sounds great: okay, um get more out of storybook html write, md docs. I think this is kind of what we were talking about a little bit offline when we were saying about finding ways to make docs just more publicly accessible like finding out like what works, not only just for developers but for the whole working group.

A

I'm pretty. I think it sounds like we're pretty open. We've talked about handbook, we've talked about creating um or creating our own page.

A

Storybook yeah I'm question mark on storybook, um just because the way I I have to look further into it because out of the box straight away default configuration, I tried just to render markdown files and it was like not liking that too much so just setting it up so that we can do that. But I don't think that would be too difficult um to do with another tool, for instance within that same repo, if storybook itself doesn't work. I just thought of that idea. Right now and it's like oh, we could do that as well.

A

If it's a problem, but I know it would be better to have everything in one place.

C

Yeah, so I think uh one of the things we had talked about earlier is kind of just getting it started somewhere, um and so maybe, if we're not set up with storybook, yet you know wherever that first place we choose, is um you know just uh action item creating an issue starting documentation uh wherever it gets put, is tbd um but yeah. That's that's kind of the uh theory. I think there.

A

Yeah, I think it makes sense to create an issue just to put things in the handbook, and what we can do is link out to other places. If we end up moving where that location is so just say like this is where we're putting our documentation right now and just put everything there and then once we have a more dedicated place for.

B

A

Can just link out to that, so it's like also publicly visible to the org. What's going on so that if someone searches, marketing design system, gitlab they'll be able to find that sort of stuff.

C

A

Okay, all right, I think, that's it is there anything else that we could improve on for things that we weren't explicitly listed as things to improve on.

B

Is there any action item from last week that we didn't do.

A

I think we need to discuss the not supporting ie um more explicitly from the engineering side.

D

B

You could like make an issue for her. Maybe.

D

B

Or is that too much? Is it just.

C

B

A slack conversation.

C

I think an issue is good, so we can document it because slack is uh ephemeral. So it's good to have that thing, that someone can reference.

D

A

A

Okay sounds good any last thoughts.

C

Not at the moment.

A

All right: well, this is our retro. Hopefully we can do something about these action items, but what I can do is I really like the ish. I think I've gotten better with issue writing, so I can start putting these in and then we can start collaborating on this for our work. While everyone is away so thanks, everybody see you all soon.

D

Thank you thanks. Thanks.