GitLab Create Editor Group, 23 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Create:Editor Product/UX Weekly - 2021-06-23

Description

Weekly Editor group sync between Product and Design

A

Hello, everyone: this is uh the product design, sync for the editor group and it is june 23rd, so I'll jump right in um I'm gonna move my stuff around real, quick um and talk about these two things. First, on the agenda, so I wanted to summarize some of the feedback that I've been um fielding in our feedback.

A

Issues for our big 14-0 releases um very excited that it's all out there and I came back to generally positive feedback and excitement which was great to come back from some vacation time and see that the content editor issue uh is not as uh probably as expected it. It doesn't hit as many people, but it's not as active. The people that are in there are universally asking for image insertion and table editing, which we knew was going to be our next effort. So that's excellent validation that we're working on the right things in 14.1.

A

um Overall people are into the idea of the content, editor and kind of see where we're headed and it's very validating the feedback in that issue. So I'm excited by that. uh Hopefully, I think, uh and I'll get to this later um on my last agenda point, but I think it also has me feeling like we.

A

We might want to move sooner than later to change the um editing experience over into a block editor and more of a full page editing like your vision document, but we'll try and figure out where that fits in and when to do it in what order um you don't need to do that in a synchronous meeting um and then in the top left, nav, uh there's very little feedback on the the left, nav um in general seems pretty widely accepted.

A

There was one bit of feedback that I've seen that echoes what we've heard in the internal feedback issue, which is that tool tip pattern for items that don't have sub menus can be a little confusing about where the click action is, and generally we knew people there were going to be some people that are resistant to change and have very valid feedback to the introduction of a new click.

A

It seems fairly universal to me that people who have large screens don't respond as well to this change, because they they see that there's room, um I'm still working on my response to the last bit of feedback, but generally, I think making it clear that this is an iterative step towards a larger change and adding more functionality in this menu while like using that space for other things is going to be a change for the better in general, so um nobody's you know, threatening to leave git lab over it.

A

So I'm happy there, um yes and so amy. I don't know if you want to voice over your comment. There.

B

Yeah I was so focused on the top nav changes that the the left nav changes. I knew they were coming and I still was caught by surprise and I realized I actually really like this. So cool yeah.

A

uh I saw the work in progress and it really came together towards the end and those last mrs merged to polish everything up. It is delightful in my opinion, so for the record. I.

C

Love the churches, yeah.

A

Yeah, it's very polished, it's it's very good, so I'm I'm super happy. It feels snappy everything um is. It is the way we wanted it to be. So I'm I'm super happy with the work for 14.00 um yeah. Anything you want to add to the feedback topic.

C

A

C

To say that, like I think this was a really good example of using feature flags really so because we had the future flag up a lot earlier. We got a lot of internal feedback so that um dennis and paul can make those polish changes prior to like unleashing it to the wider audience. So yeah, I'm really good with that, because yeah it'll be a total different 14..

C

If we didn't release what the future was like and so happy with that um and yeah more polished to come because yeah I've been looking at some of some of the other concerns from the feedback. So for me, I'm almost happy but he'll get there for me like, like you know, you can see the imperfections with this and that but yeah, I think it was a great team effort.

C

I'm like yeah, really good execution of the way the teams were like kind of grouped up with friend and dennis working on the sidebar and like chad and paul and the top nav, and how things just came together. Yeah yeah yeah. I agree. I agree.

A

It's been a it's been a great, um it's been a great team effort and to watch them come together and work on these separate um areas, but share learnings as as we went along was really great. um I think the next point, um oh so yeah amy. I don't know if you want to share you, don't okay!

A

Well, yes, the feature flag approach, helped a lot I I would say for for future planning uh if anybody's watching this and attempting to ship two massive redesigns of our global navigation simultaneously in a major release like bacon in one more milestone where the feature flag is on internally, or something like that or like in a control group where we can continue polishing, um you know, there's always something you can do with more time. It can always use more polish.

A

I feel good about the what we shipped in production, but I feel like we knew some of this feedback was coming and we could have had another milestone to address it before releasing yeah. Hindsight, though, uh speaking of hindsight uh for future reference, um I was struck by my this is a shortcoming on my my side for not communicating this.

A

In a more global way or baking in the time to find a way to communicate this in-app, um but we moved a lot of things around on the left nav and I kind of just naively thought that there's a learning curve, we have issues and epics that people can follow along, but obviously not everybody's, like in our issues every day.

A

So when things like labels moved to project information, we tested it, we knew that it was a better end result, but we didn't communicate that clearly even internally. So I had like the pm for plan like asking me where labels went and I realized you know that could have been better communicated. I don't know if that's docs, because not everybody reads the docs. I don't know if that's in-app notifications, because we had so many changes that an in-app notification would have been cluttered and and unclear anyway.

A

It's possible that this was the only end result given the scope of what we were doing this time, but just something to consider for next time or open to feedback. If you two have it.

C

Yeah, I think pinging, the relevant pms we've been like the right thing to do here, um kind of like what we did with that create new project kind of stuff. Where to create new group, where we brought in that group to say hey, we want to change all these things about it, and then they were like cool. We did some like testing on our side and we're happy to make these changes or whatever. So I think there was awareness from that side.

C

The stuff with like moving members uh was, like, I think, a joint effort, as in that cover agreed um yeah. I think we just missed miss linking up the labels one because other than that did you get anything else.

A

I saw that in a couple I saw that from a couple places I think that's the biggest one where it was like. Maybe that's just the more commonly used one and the feedback for members will come later when people try and change the numbers of their project, but.

A

I I would have expected more in the reorganization of the operations menu too from from users, not necessarily internally, because that was collaborative and pretty well documented.

A

um This might be just bias from the feedback coming from the pms and and recency of that feedback, but it does seem like maybe there should have been a more easily accessible and concise list of like this menu item is changing to this location, and this you know in the past what I've seen others do is like leave. The notif leave the item in two places and say like it's moving over here or in the docs comment, but it was so there were so many things changing that doesn't scale anyway, again, there's nothing.

A

We can do about it right this. Second, we could probably write that concise, summary in an epic, an issue or issue and point to it somewhere, just to make sure that, like folks on support and whatnot can have a reference, but um yeah.

C

Yep, another idea is just to increase the future flag group, uh so, like fyi people like you're, getting this feature flag, and this is why you're getting it or.

B

C

Is why it might affect you so with the feature flag? What I realized is like we've been talking about this a lot since february, like yourself and myself, and doing like ux showcases and like sharing stuff in slack, but not everyone reads and absorbs the information this.

C

You know at the same speed as what we're thinking about things, and I think it's only when the pixels hit the screen that people like gave really uh constructive feedback. That was useful. uh So it's probably you know that someone in that group of uh responsible for labels could have gotten the feature flag earlier and be like hey what's going on here. um So maybe that's something that we should consider like. Yeah feature flag for our group first and then thinking about who should we expand out?

C

So maybe the onus is more on us because we're making the changes there, but yeah.

B

Explicitly, including the pms and ems in a feature flag, rollout seems like a a reasonably simple and measurable change that we could try next time.

A

uh I guess just for the record I did include, I opened up the opportunity, and one of them at least, was in our initial feature, flag, rollout and just didn't come up as um as feedback until later. So, yes, uh being more explicit and and again having a little more time to roll that out gradually internally would have been ideal.

B

The toast message idea I've seen evernote do that when, when they move cheese- and I don't know if a dismissable message like that would be helpful, but I saw them do it a few days ago.

A

Yeah no and it's that's that's something where I feel like the time crunch hit me and uh and the team, where a little more time and a little more preparation. We could have done something like that in app and.

A

Yeah, I think initially, our our idea was to use the broadcast message on the top, but then we've we discovered through the process like while I was out, michael and and paul discovered that, like that, wasn't necessarily the proper use of the broadcast message and um there are other ways to handle that notification.

A

um With that learning, I think next time we can be a little more intentional about building in pop-ups or tool tips or toast messages in certain places or on certain views, um so yeah a little bit of lessons learned there, but yeah. Luckily we're not actually removing any functionality. So it's it's a little bit of a learning curve. Hopefully people will get over it.

A

If we, if we find increased or continued confusion, um then maybe our research was not uh comprehensive enough and and we could review you know we could revisit the decision, but I think right now: it's just something new took people by surprise and they'll figure. It out.

A

So, on that note.

A

We would like to move back to some of our other categories for a little while now that we've shipped all this navigation work, but I understand that there are some. There is some work. There are some issues and bugs and refinements that we want to carry over.

A

So I just want to talk through some of that. The the area or the bar for getting these done in the next couple releases is pretty high in my mind, so it'd be like things that are really critical or polish items that are just you know like very, very clearly unfinished. So um I had some ideas.

A

uh I created an issue based on the feedback, but we had talked about this before, but the the feedback on how many clicks it's taking to get to projects or navigate the top menu. One of the ways we thought about addressing this was using a hover pattern to display the um left or the right panel, the detail panel.

A

I still don't know if that's the right answer, but I feel like there's a small iteration there that we could make potentially to reduce the number of clicks.

A

The empty states of that.

A

Panel, the detail view for each top level thing was another thing that I'm just not sure the value is there immediately, because we haven't received enough like input on what would go in those detail. Panes for all of the items like for us, snippets is pretty clear. I think um you know, activity is pretty clear, and maybe milestones is is pretty obvious, but operations and security not quite sure what would go in there.

A

So maybe that's not work. We need to pick up like in the next couple milestones. I don't know how you feel about that. One.

C

Yeah no like on the scale of like things to fix from there like yeah, we can debate about that. um I shared our kind of idea with the growth team as I, this is potential screen real estate that you could use to do something here. um Milestone snippets are kind of like, like you said, there's something to do there. The other pages are kind of interesting because they're, essentially dashboards and it's like it's a dashboard.

C

So it's really hard to say: yes, we're going to present something useful here, um so we could wait or you know, maybe we just proceed with just a hover thing. Yeah, like.

C

um Not too fussed either way.

C

Yeah, let's, let's weigh it out with how much work needs to be done. I think there's of that list like the ui polish like. I would rather focus a bit more time on that, like the colors and.

B

C

And um handling the feedback around the way our tooltips work you know versus like the pop-up menu. um I I feel like there's some quick things that we could try out for um near release where we just make a small adjustment to our tooltips so that you can't help click on it um or that can't like move your mouse to it um like a normal tools tip but yeah.

C

So those are like. I recognize that we want to move um on to some editor stuff, so yeah, let's, let's discuss that and asian constantly about what we feel is most important, but I think you and I seem to be on par with like where we want to take things.

A

Yeah and I see the link to the epic you've got there. I agree, I mean two, the two of them, I think, are scheduled for 14-1, I'm not sure they have the deliverable milestone um so they're not necessarily assigned to anybody.

A

I guess they're just coming out of design, so if we can get those playing for fourteen one or fourteen two, that would be fantastic um and then potentially the the like.

A

The hover pattern, exploring the hover pattern or ways to reduce the clicks. I think the other possibility we see in the feedback is just like automatically focusing the search field, which I know we've gone back and forth and discussed in issues before, and that has implications on keyboard, navigation and accessibility for screen readers, yeah.

C

So that that, like keyboard, focusing thing that is like like focusing on the search, we took that away like three four months ago. So it's like some people are realizing it now. But it's been like that for a while um yeah yeah it does. It does make sense uh so, but I think that can be handled like exclusively from this just like how adding and removing that happened exclusively from the navigation work so for sure.

A

Yeah cool, uh I think we're definitely on the same page. uh The only other thing I need to talk to fran about the refactoring of the group sidebar. Since that didn't get done. uh I don't want it to get too stale, but it has a fairly large time investment. It's probably a full milestones worth of work, and I don't necessarily.

A

uh I don't want it to linger, but I don't know if I don't.

B

Know when it's.

A

Going to be best to tie them up for a whole milestone.

A

So that said, uh moving on to the content editor, um the feedback has me feeling more confident about the block, editing approach. um So I just wanted to check in again now that you've had that had an opportunity to let that sit and simmer for a while.

A

How confident are you with that overall direction, and- um and when do you think that change should be made.

C

So when you say block editing, what exactly do you mean by that in the sense that like so so when the so there's that other issue that msu raised with like selecting a bunch of various.

B

C

um Whether you can select them individually, one at a time or like collectively together that I think this is what comes down to block editing. I think if we force people to not be able to select everything at once, that's going to be painful. um First is: if we can solve that, then it makes no difference.

A

So I I think that the.

A

The the shorthand, when I say block editing what I mean is moving away from the toolbar into something. That's more of that contextual block element menu, that's on each line. So if I hit return, I have a little menu near my cursor that I can insert a header or a line, break or a table or something like that and then move towards the formatting type options like bold and links and stuff into a tool tip that shows up when you select text.

A

I think that pattern is what I mean when I say: move towards block editing, because some of the feedback is like yeah, the editing, window's real small and the toolbar would be better to be pinned on the top so that, as you scroll, it doesn't move away, and things like that, which is all true, but I I hesitate to invest too much time into optimizing for the toolbar, because we've pretty clearly determined that the block style, contextual, bubble menu thing is a um a familiar and you know pleasant, editing experience.

A

I don't think it's exclusive either. I think you at least the implementation in tip top. I believe you can select multiple block elements at once to delete them.

A

C

um So my two cents on this is yeah. We moved to block editing and we keep the current editing area as is right. Now it's like you, haven't really, it's still painful, um so the other piece that we kind of explored very briefly was like the page redesign kind of kind of like breaking the page like relaying the page, to use the space uh more.

C

So that could happen um at the same time as for me, the toolbar is almost like a safe playground to start, because what we're also doing at the same time, is converting a functional or like introducing functionality to the content editor. So that has to be like usable, whether it's in the toolbar or floating the thing. So to me they can happen mutually exclusive of whether.

B

C

C

Menu or not um or like block style, editing experience. So that's to me: fine. um If we go full block editing, we just need to yeah. I I think it's worth experimenting with in the wiki world, because that's a scoped world, and that has a lot of users and then we can use that to inform whether we should do it elsewhere. um No, no concerns with that. um The framework that we're using it is designed to do easier, so it makes no there's no real concerns.

C

The only thing that we got from solution. Validation is like whatever you introduce in the block editing, so it's make sure that it's that you can access everything. The only time.

B

It was frustrating.

C

Is when you can't access something that was in the toolbar? That's no longer here. So in that solution, validation, I was trying to be clever to say, like I'm, only showing you formatting tips here versus uh adding new content, so first nbc's, potentially just including everything but um and that will give us feedback on their experiences there. So we can experiment with different things like rolling out to 10, or I don't know if that's even possible, but it's something to think about yeah. However,.

A

Oh, we can definitely.

C

Like try, the new content editor right, so that's it's an opt-in experience, so yeah! Let's go with that, because it's in it's being developed, so we had that messaging around it. So we can change at will so yeah.

A

Yeah, I think, in this initial period, before it's the default editor for wiki markdown content. We have a little more freedom to tweak that experience. So if we're going to make that kind of change now's the time to do it for sure um I will chat with enrique and himachu about the effort there.

A

It might be something that we need to pull in a third front end to tackle the view restructure at the same time so that it has more room to to breathe um yeah, we'll get it slated soon.

A

I think images and tables are more important, so we're working on the right thing right now, but um I think pretty soon we'll want to invest in that experience in general um yeah cool um as we get closer, and we can do this all async and issues and epics, but it could help them and and just because there's so much terminology to have some clear, um some clear guides for providing estimates and understanding like what structure we mean it doesn't have to be comprehensive, but a couple of views, even maybe from your solution- validation that already exists, making surfacing those up and making sure that we're all talking about the same thing would be.

C

A

um That's a lot of my stuff. I should have let you go. First. Sorry.

C

A

C

You yours, your stuff is my stuff, where one team, so it's.

B

C

um So yeah still um from a to-do standpoint like we talked about the commit flow like um holding a think big session from it, um we don't have too many like existing issues been linked up. So I yeah.

C

And then this week a few people are off, so maybe we schedule that for some mid next week or thursday next week or something like that and days are kind of, or do we just talk about it asynchronously.

C

This is where, like I'm kind of what I kind of the feedback that I need is like what are we trying like high level ideas so that we can start like thinking about a the problem that we're trying to resolve with the existing uh commit flows and then ideas on how we might improve that those if yeah, if I had to break it down to that, that's what we should really need to do. We can.

C

We don't need the thing big session if we get everyone just to insert the two cents about it within the group, um and then we can use that to frame like the problem statements of why we're doing this like. Why are we changing the commit flow?

C

um But right now the like one case, for it is like consistency like every time you go to a new editing experience of gitlab there's a vulnerability step. So you know this. This one's different, this one's.

B

C

This one's different so there's a there's, a motivation from that standpoint. But is there something else and that's what um that's the question I have because you.

B

C

Are we're kind of new to web id versus like dennis and other people within the team, so he's just trying to get an insight on what happened before us that, like people have thought about?

C

uh So that's why I was hoping with the linking to old issues and stuff like that, so that we could get a sense of where people were coming from, but uh yeah. That was the goal just think big. But I really think if we asked the right questions, we could do this async.

A

Yeah, that's a that's a good point and maybe the think big needs to be.

A

On the books, so we have dedicated time I'll schedule something and make you and I the only like required attendees and we'll find some time that works for us and then, if anybody else can join and offer perspective, that would be beneficial.

A

um It'll probably be for next week anyway, just to give us time to prepare uh when, when more people are around and then and then we can use that as a we can record, it use it as an artifact to spur the conversation and and get other people to contribute async. um I I'd like to think about it. um Yeah I'd like to think about it more and get some ideas in an issue.

A

I I'm glad you you set up this issue to to gather um you know sort of previous research or previous issues on on the topic. I think it's it's going to be a tricky one, because there are so many places where you can commit to a repository from the gitlab ui.

A

It's hard to build one thing that serves everybody's needs, but if we can, if we can find some common ground and ideally optimize some kind of uh do some back-end work to optimize the the flow there too, that people can use to influence whether or not they use our shared component or not it. Maybe it's. Maybe it's irrelevant.

A

If, for example, the pipeline editor doesn't want to use a floating menu like we do on the wiki, if that's how we end up doing this, maybe that's not our top concern, but the fact that we've optimized the endpoints so that the.

A

The inputs are clear: the expected and required inputs are clear, it's performant and you get good statuses back and that can inform executions even beyond what we end up doing on the front end. It's kind of yeah yeah.

C

Yeah on my side, I have a lot of ideas. What I don't have is a real problem statement of like what the existing pain points are.

C

I can think of different ways to like assess that out, um as in like we can do some problem validation sessions to go through and get some feedback, um but a lot of the stuff hasn't changed in a few years. So I'm sure this existing documentation, nadia, like highlighted some points around the pipeline, edited a team like with they kind of went with the mvc approach and just like emulated the same thing as the single file editor and yet there's uh some stuff that they wish to improve upon that.

C

That could be shared across um other things.

C

There's ideas that I have in my head around like progressive, like enhancements uh between like the different context, like you know, a wiki. What do you need to create a snippet from there or like.

B

C

It like something that you unlock like advanced options in that view, but by default in the web ide, it's like full-on kind of like.

B

C

Calculator and a normal calculator and.

B

C

Iphone would you just like rotate in, like oh scientific mode, um just yeah, so there's tons of ideas where I'm missing is like a problem statements uh to hook them to.

A

Yeah, I'm I'm revisiting nadia's comment in there and I think that that it's a really helpful summary of the challenges and highlights probably the pattern that that we would need to address, which is that there's not really been a chance recently, where somebody just took a step back and looked at the process of committing changes in gitlab. It's like a single file. Editor had this view, so we just copied it and now it's in two places, but it still has the same drawback.

A

So I think since single file editor, it's you know it's in the repository view. It's not technically a product, it's not a category but like we. We can impact it.

A

If we look at that as a use case separate from uh wiki and separate from web ide and find commonality between those three, where can we improve the experience across all three and then, where can it be enhanced or extended to be more useful in each context? I think that's a that's a great start.

A

um So, let's, let's get that on the books, we can talk through all your ideas, get it all out in a brainstorm and then start working on it.

C

Cool sounds good. Let's do that um yeah and the other thing um embed, embedded snippets. um I know that you wanted to aim to have this ready so that you can work with an intern pm um due date like, like. I haven't had time to look at it, so I I need a foursome function here, like if you say next friday. Am I cool done because yeah what you were asking for? It's not.

B

C

Super detailed, it's just like a high level kind of rough thing, so yeah.

A

Yeah, uh that sounds good. I think, uh thinking through the cycle of how I'd like to work with that internship. I think a couple more high-level conversations before we dive into breaking down the mvc sounds perfectly acceptable so, like let's say july, 2nd yeah.

C

I'm just going to say july 1st, because I'm only july 2nd anyway, so no problem.

A

C

Good awesome, cool and then my last point is something to like think about ponder, as as we continue on here is onboarding feature like onboarding users for features within the content, editor. So a float like. Let's say we go with the block editor like how do we?

C

How might we like inform users that this these features are available? So one potential area here is just um the ux team. Has this other initiative of doing a few analysis of like kind of setting the benchmark of how other products do certain patterns like different jobs, to be done? So we could do something similar for like editing platforms, um but there's a lot in our current. Like comments, editors, you know like the backslash for um the quick actions, that's like once we get into that world, um inserting content like images and things like that.

C

You know what's possible, what's not possible uh trying to marry the world of documentation meets product. I think there's, it's a so. I shared a video in the art group chat about like uh tutorials for complex games. um It's really interesting, uh video, where I see a lot of the content and editor stuff is like some of the stuff in zelda, where you learn to fish. You know it's like do this action and then you'll you'll get some fish.

C

I think there's the content editor to me is almost like a mini game that teaches you like skills to like level up in the whole game. um It's not like a whole campaign. It's not like wow! You, like conquered content, editor. It's like here's, here's another tool, here's here's another feature of it and yeah, something to think about. As as we like build the content editor because going into block editor mode, the default view is almost like a blank page. So it's like yeah, um which is very different from.

B

C

um Ui, we think a lab that has like everything available on the screen, so something to think about.

A

Yeah, absolutely um that I'm glad you're um thinking about that and it's I think the empty state of a new page in the content. Editor is something that we should definitely explore, and even I'm thinking like, I think I'm trying to open up notion at the moment- and I was locked out but like like even when you're on a new line. It reminds you um that you can type slash and get commands and then there's a menu that describes each one. um I think possibly medium does the same thing to remind you about slash commands.

A

um I think we can take a lot of inspiration there to guide people through and maybe even like, be clever about when we get to issue descriptions and and epic descriptions like maybe after you type some content, we change that tip to like, say, add some labels or something like that or um you know we need to be careful because not everybody uses labels and milestones the same way. But finding ways to like promote discovery of these advanced functions is. Is that that's a huge opportunity?

A

So I I like that you're thinking about it already um yeah, let's, let's keep that in mind and maybe that's part of the early bits of that as part of our um our switch to a block editor.

A

Even if it's not slash commands at first, because I don't know if that's gonna- that's probably not gonna come for free. That might take a little longer on the iteration timeline, but say you create a new line and there's like a little bubble menu on the left in the gutter, like maybe that placeholder text explains like what you're looking at, and um I think that could go a long way.

A

Confluence does some stuff about like empty page templates. When you create a new one um and I'm pretty sure notion, does it too, when you first create a an account in a project there's, like maybe pages that are pre-filled out? I don't know if the wiki is that appropriate for it, but we could do that for like issue templates.

A

um Potentially we could look to uh work with the plan team to make those a little more interactive.

C

Because if you do that, if you get it into an issue, then you can get it into onboarding. So when the users uh creates a new gitlab account they're taking to like a board.

B

C

Lab board, with a bunch of like to-do's and all this stuff part of that one could be. You know edit. Your first sort of like fix your first uh issue and then in that it's just a bunch of actions, and then you just like highlighted this and then you click done.

B

C

Like a step uh in the onboarding process of like how to write in getlab, so I think yeah that that requires some work with getting our content editor up to the par, uh so that you can do everything the issues think and but yeah borrowing that I think that's a good uh goal to reach to.

A

Cool yeah: let's, um let's keep that in mind, I think moving to a block, editor kind of flow is a great time to introduce some of that education and and then, when we get to issues that onboarding board. uh I know I have an issue out there somewhere to explore like how we can bring the web ide in there, and um we can create another issue for how we can reinforce like editing in the content editor as well. Yeah.

C

The other way to do onboarding is just like when users use the action, so you know using the wiki world. You know if you entered like bold with the toolbar, it suggests like. Oh, you can do this by keyboard as well, and therefore we actually decouple ourselves from the main onboarding and then we're kind of like the forever onboarding flow. So whatever you deal with, whenever you use bold inside a content editor, we just pop that thing and then the code that that step is done.

C

uh Yeah many things to do something to think about, while we're going through this world but yeah. I just wanted to put that intercept that idea in your head now before we jump deeper into content, editing.

A

Yeah I like it thanks for bringing it up great.

A

Well, uh we're well over, but I um yeah we haven't had this in a couple weeks, so it's great that we could sync up I'll. Let you get some sleep. I know it's late for you and uh thanks again for covering for me and for managing everything. um uh While I was out.

C

Nope good to have you back yeah.

A

All right um take care I'll talk to you soon.

C

See ya bye, see.

A