GitLab Create Editor Group, 16 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Create:Editor Product/UX Weekly - 2020-12-16

Description

Weekly Editor group sync between Product, Design, and UX Research

A

All right welcome everyone to the product and ux research, weekly sync for the editor group. This is the december 16th edition, which I just realized. I probably had a meeting earlier today where I called it the december 15th meeting, but that's okay. Who cares what day it is we're just catching up on all things editor, so.

A

I only had one agenda item, but I kind of want to get to that last. I'd rather hear a little more about uh design and research this week um and if we have time we can get to mine.

B

A

Will go I'll, go first.

B

Well, michael's. Writing this point. I just have an update that I literally right before this meeting wrapped up my last session for the benchmarking research, so I'm starting to work on analysis for that study and for the tree test. So that's that's gonna, be that's gonna, be what I'm, what I'm doing over the next couple of days, um do I will be setting up dovetail projects for them.

B

I have one for the benchmarking study, but I haven't completed the analysis yet, but if you're curious about the videos and such you can just take a look at the dovetail project early, um let me look at eric's.

B

Actually, could you revolution.

A

Yeah, so the I think this is related to the research you're doing on the tree test for the left, nav and and baselining that experience um just calling attention to an issue that I pinged you both on, I believe to earlier today that is labeled ceo interest because it came up in one of the scaling uh meeting, agendas, uh items and it. uh It relates to like consistency around whether that um that top level left nav item is clickable and where it goes.

A

Whether it goes to the first item on the page or it has its own distinct, landing page separate from the items underneath it. um We were talking about this a little bit michael in the context of rearranging the left, nav and being consistent about how we apply the the patterns around like sub items um and then how we would extend that to things that don't have sub items like and need just one view, for example, requirements or wiki which don't have sub items at all the issue. In particular.

A

Let me see if I can find it real quick, but it doesn't have a ton of detail, but it basically is just like. We should standardize on this, because it's repetitive to have two click targets that go to the same place.

B

I think I did see that and yeah so so that isn't part of this particular study, but I do think it all it makes sense. It is probably also important on mobile. I think I've.

C

B

Problem come up before where someone was trying to get to the page on mobile or something, and they can figure it out. But I'll. Look into that to see if we have anything related to that in our research.

C

Yeah um regarding the click, uh the interaction, it's something I'll- probably tackle- um I'm just gonna say next year, but it's only like two weeks away, but uh it sounds it's not really far, but uh post holidays probably take a look at that, because that's more like an interaction uh thing that we need to sort out, and this ties into this pattern where we have like where we want to select the second item and like, like the first sub item into this and then there's cases where we don't follow that pattern and, for example, in analytics.

C

The first thing: that's effective is the last thing, and so there's little things like that, where I think hope looking at all this stuff holistically and then aligning it with some of the left. Nav research will help find our direction from there. Because there's another issue out there. That says every page should have a first sub menu landing page.

A

So yeah there are other related issues and clearly it's come up like before, and it's annoying enough to have the ceo interest tag on it and be discussed at that level. But it, um in my mind, is, is much more around like consistency. We just need a consistent pattern for this. We probably need to test what makes sense to our users, but also what makes sense given whatever.

A

Ultimately, we do to rearrange that left nav if we shift things out of different groups and and break things up or organize things a little differently or at least make recommendations for that. I think whatever our recommendation is, should include a standard standardization of this pattern, and so it's applied consistently.

B

Okay, okay, so there's so there's two parts to it: there's the interaction and then there's the question of: should there be a landing page or does it even make sense to have requirements list or issues list that sort of thing? Okay,.

A

Right so I think that yeah, the the real this is not this. Is it what looks like, probably a hastily written issue um and it's from a year ago, so it doesn't have a ton of context but- um and I think even the screenshot's out of date, because the icons look wrong, but the the general gist of it is like. There's a there's, a top level net of item for something like cicd when you click that, where does it go? Is that the first item on the.

B

A

B

Yeah for most of them, it is, I think, the only thing that I remember from the top of my head is value stream. It's analytics goes to value stream now because I think that's probably the one that either the one that came first or the one we're trying to highlight for some reason, but I think it goes to value stream and that's the one, that's all the way at the bottom.

B

The the usual pattern is for that top level, one to pop up to that first item, which is why it's also is, is not necessarily ideal, but it's interesting. That analytics is the one that differs from that.

A

Yeah and and in particular something like issues where it says issues and then list like it is a little repetitive and I think the suggestion in the um the issue that was linked here in the agenda was like: don't make that top level one clickable when you're looking at a expanded list, because then you have two targets that go to the same place.

A

um I would say, alternatively, we remove the concept of these lists pages and full and that's one less item that needs to be on that view, because it's the default view or actually now you wouldn't remove it from the view.

A

But potentially you don't need to make the the title clickable once you've expanded it or something like that I'll leave that I'll leave the solution in more capable hands, but uh know that there's there's some pretty um a pretty high level of interest in getting that figured out as we shift our focus to the left nav in general.

B

Yeah- and so I mentioned mobile earlier, but I realized that not just mobile. It's also when that left sidebar is collapsed, is when it's.

C

B

Important because when it's expanded, if you click on the top level one you can see that it's gonna highlight list, but when it's on mobile it just looks like two different locations. You can go until yeah expand. So I see.

A

Or when it's closed, there's other there's other discussions on this um issue related to that, and just like.

A

Some input from the foundation's team already, so I think we just need to um fold whatever solution. uh We come up with into what you know what we recommend. The new architecture of the left. Nav information architecture would be.

B

Good but yeah, so that was uh my main update, is that I'm currently working on analysis?

B

They are very interesting sessions, um definitely brought up a lot of questions around project level, virtuous group level, and how to even talk about finding things that are global, um like in your instance versus in a project versus in a group how we have all these different search, bars and filters everywhere, and people were users were kind of having some trouble figuring out, which one to go to first to find something depending on the level.

B

So there is a lot of interesting things around that and then another interesting thing that came up was when trying to switch from a project to another project.

B

The specific task that I gave them was to switch from one issue board an issue board and one project to an issue board in a different project, and that was when there was a lot of like do. I just click back into the breadcrumbs like define the group and then click back into it or is there? Should there be a simpler way to go from the issue board in one place to an issue board another place? I thought that was an interesting one that came up and then from a project to a group.

B

It was also anyway. I don't know why I'm starting now, I I will basically be working on pulling out the themes from that and some of the interesting patterns that I saw, but.

C

Very interesting um I was just so in the solution- validation that wrapped up last week and this week, I'm still going through the notes. um My goal for today will be sharing out the insights notes for um the top nav consolidation, but the main things that I tested there was like consolidating project screws and more into one, the user menu simplification on the top right and then switching between uh different projects. uh So one is to board to another issue board.

C

I took that kind of task directly from your um discussion guide, catherine and then use that in mind to like help find some parity in our research findings and yeah. Some interesting bits in there about making it simpler to navigate and and I'll go in more detail in that issue. But one of the things we explored was having navigations within the breadcrumb so like a drop down like in the breadcrumb area and yeah people really liked it.

C

But um I have concerns about in introducing another area to like potentially switch your contacts, and so that's probably the thing that I'm going back to to take a look at the bigger theme which is like switching between projects and groups, um because some people were like yeah. Sometimes I switch between issue boards but like of projects and then the group issue board, because those are different too, so they they were like. Oh, this drop down should also allow me to switch groups and I'm like.

C

Oh, this is getting wild and so and that's probably why I wanted to hold back on switching of the breadcrumb, because it won't be a consistent experience across all areas of the product and, like let's say one, one project has a wiki in the end that it doesn't then, where you're going to take them back home, and it's like cool like in that instance. It does that, but sometimes for another project. It doesn't do that.

C

So this will probably introduce more inconsistencies in the world, but there are some bigger themes around like switching projects and groups and how do you make them easier? So that's probably one of these things that we'll take on as a actionable insight to like um do more more research on a better solution to switch between projects and groups.

C

um Interestingly enough in the consolidation of projects, groups and more people thought that they could just search projects and groups in the drop-down like together, because no one knows what's going on between projects and groups. So it's just like. Oh, I wish that was combined, so that was yeah an interesting thing there.

C

um Yes, so that's the goal for today's just sharing out those insights and hopefully um kick things and like set things up nice for um posts uh time off, and the other thing that I was looking at yesterday was um just refining some of the patterns around how we might do tables.

C

um Let me add a better link into the description.

C

C

Yep, so I think I'm in the okay position to start looking at um writing a discussion guide for settings and kind of framing that to uh help understand what we wanted, who we.

A

C

Recruit for uh for the settings and the settings solution, validation, so.

C

Yeah um yeah, that's pretty much the things for me this weekend this year.

B

Very much in uh getting it all together and analyzing mood as well. It's it's really cool, but you have to like go into each video and see where they were going. So that's kind of the rest of the rest of this year. For me as well- oh another one though another interesting one was.

B

I had people try to find the gitlab.org group, because I know that's something that I run into challenges with a lot um and that one was an interesting chase, um because sometimes people would try to first start by searching in the groups drop down just gitlab.org.

B

But since it wasn't- and I don't really know what the logic is, but it wouldn't show up there in the search. I guess because it's not their group and so then they would click on maybe explore projects explore groups and then try to search for it there and it wouldn't show up first and then they had to kind of do this sorting and all kinds of things to try to just get the gitlab.org group to show up.

B

So there was definitely something there about finding that specific group, but maybe that's also a concern for finding groups in general um yeah. That was interesting.

A

I'll say that if, if gitlab.org is not on my frequently visited, I can't get to it easily the box, I mean it just like I type in gitlab and it's pointless.

B

But why like this, has been a question I've had I.

A

Don't know, I believe, there's an issue, I don't know where it lies, and it is certainly something we can pick up if, if and when we um work on that change around the projects and groups menu, but the logic behind that search feels quite.

A

B

We have time for your point.

A

Here, yep, I think we do so. This will be interesting. I just wanted to share.

A

My intention is to review this opportunity canvas with with folks the probably the second week of january when everybody's kind of back in the office and we're back up and running um and get review from. You know the product, leadership, team and potentially some folks from design, but I thought I'd run through it with you, almost as a driver on and and share how I'm thinking about this rich text editor from a product standpoint and our like.

A

You know the potential opportunity we have there, because we.

A

We haven't reviewed these as a team before the opportunities with the static site. Editor were fairly like tactical and well-defined.

A

um This one is one where there's a little bit of a larger business case to make and just kind of sharing a little bit more context with everyone about why we're building it. So let me just share my screen. This will be the first time uh outside of one-on-ones that it's been shared, but for anybody watching the video.

A

This is what our opportunity canvas looks like um and yeah. I think that, uh right now, the primary focus or the primary opportunity is driving consistency, editing experiences and, in particular this one around rich text, editing experiences so working with content that would typically have been written in markdown, but you would like to have some styling too. It's not code. In other words, um the the issues that uh that I link to are are very much related to the architecture that we've been working on. That enrique has been working on for several milestones.

A

um I feel pretty good about the problem space and how sure I am that this is a problem that exists.

A

We have a pretty um a pretty well documented opportunity in the static site editor, but uh when it comes to the business case in the larger gitlab ecosystem and gitlab product, there are plenty of issues and feature requests for um woozy, wig style, editing and there's been explorations in the past as we've as we've learned about implementing this in the rich text editor, I don't know why this is um not loading, but I could have just well I'm still on zoom, so my internet's not down anyway.

A

um I think the the interesting thing about this is the customer's slightly different, although we aren't necessarily ignoring our current customers. This would ideally open us up to more collaboration among product managers, designers, support sales and other personas that are less familiar, writing and code or markdown, allowing them to more confidently and more quickly contribute to issues to wikis to the static site, editor and anywhere.

A

This is implemented um some of the problems that they run into here, that I've noticed and- and this is where I think you can both challenge me or add any context- or let me know if I'm not hitting this right. But um for me it's a it's. It's really about confidence. It's about like anybody, can learn what one hashtag and two hashtags like end up.

A

You know pound signs what those do in markdown and anybody can go reference, a markdown link and copy and paste it, and we do have some quick actions in like the issue um boxes that that help a lot. But um the confidence comes into play when, when you are toggling back and forth between the writing view and the preview view constantly to just make sure that your formatting is correct, that it's going to look good in the end.

A

Personally, like I never use the preview, because I know relatively what markdown is going to look like, but I've messed up syntax before and so I hit submit on something and I have to go fix it, because um it's probably like more muscle memory for me that I'm just gonna write and then find mistakes later rather than preview, but for those that aren't as familiar with markdown um there. I think there's a lot of friction around the like I'm gonna type, a little bit and then wait. Did I get that right?

A

I'm gonna switch over to preview. It I don't know. Oh now I gotta go. I can't write in the preview, so I'm gonna go back and write some more and where was I and now my train of thought might have uh left the station so to speak. So I think this is a pretty um that's. That's at the root of some of this. uh It's not that markdown is inherently difficult to learn, but even after you learn it the basis and even some of the more fluent markdown authors will still find that you know.

A

Writing tables is a lot of trial and error. Like you, you don't just write a complex table from raw markdown. You either paste it in from somewhere else or you do a lot of like trial and error, flipping back and forth, and previewing um yeah. I mean the uh the the secondary goal here. I guess is that we're addressing potentially a workaround that's happening and um that's like writing locally. So sometimes you know people write in their local ide or a local markdown text editor or even google docs, or something like that.

A

They'll author, a more lengthy response or a like an issue description or something like that and then copy and paste into git lab.

A

Keeping people within the git lab ecosystem, I think, is going to benefit us in the long run and making it easier will help us grow numbers of seats and stuff, like that within organizations that already have gitlab, because people will be more inclined to do their work right in the product.

A

At least that's my my hypothesis.

A

um I don't know I guess these numbers are on our performance indicator page, which is public, so there's nothing sent. We can record this and put it public, but I'm I'm estimating our reach- and this is this- is the important distinction that that I want to hit about both the work, we're doing with editor light and the potential rich text editor here. um Aligning our editing experiences around a single like editing engine is gonna.

A

Allow us to learn a lot more about how people write and edit content within gitlab, because we'll be able to uh consolidate those actions in uh aggregated and deduplicated ways. So we can really see how many users are editing code in gitlab or editing pros in gitlab and how many are doing it outside in in their ide or somewhere else.

A

My guess is somewhere around a 400, 000 user monthly, active user like target once we roll this out, because I think we have a combination of wiki issues. Epics mrs static site, editor, potentially snippets, which I should add here.

A

A

Which I need to get the numbers for, but that's several thousand um now I don't anticipate as far as business case goes. I don't anticipate us. um You know, selling on this feature. This isn't something that we're gonna go like increase our like sales pipeline just because of this feature, but I do expect to see greater efficiency in people's collaboration, which would hopefully drive some growth, both in overall usage and um growing seats within existing.

A

Existing customers existing installations so uh fairly.

A

Confident about that honestly, I think the um the only thing that's an unknown is uh nailing the experience and that's where, where michael we'll have to finesse this and make sure that we're not um over indexing on the wysiwyg stuff and still allowing pro users and people who are fluent in markdown to write in a way, that's familiar, uh slack being the most recent and most visible offender in this uh space recently, where they introduced that sort of wysiwyg bar in the in the message bar and um everybody's, used to writing a markdown all of a sudden.

A

Couldn't I think that our architecture and the proposed libraries that we're using we'll solve for this right out of the box. But it's something we need to certainly be aware of.

A

Anyway, skipping ahead, because you know we don't need to talk about this forever, but.

A

um One of the things I'm really interested in actually came up recently related to a very specific issue, um and that was a request that I think had been around for a year or two to integrate draw.io diagrams into the wiki, and it also, I think, had been there's an issue for.

C

A

It with like issue descriptions um and the the opportunity we have here. To sum it up is if we have a rich text editor that is extensible and reusable in multiple across multiple categories, then what we can do is implement the rich text, editor in multiple places and extend it once to support draw.I o. Now, once we finish that work, the wiki can use it, snippets could use it static site, editor could use it.

A

You know, issue descriptions could use it and anywhere we implement stat of the rich text editor. We could inherit the ability to to parse and display draw.io diagrams. So not saying that's our number one priority, but it did come up as something that has a lot of thumbs up for that issue, and I think a lot of people would be happy to see it and being able to implement that once and roll it out to multiple categories would be pretty compelling.

A

I won't hit every box, but that's kind of just, I think, from a product strategy level. I I hadn't really done an overview like this, with with many people about the the larger opportunity, with the rich text editor and uh figured and share here and and continue. uh The discussion in the group for whoever is interested.

B

Yeah this is super interesting and I I personally I'm very interested in it because I have learned marked down over the years, but still I am, I am in the population, that's constantly switching between preview and like the other field that spoke to me so super interesting to me.

A

Yeah, well I mean I, I think, the work we did in static site editor pretty well validated then like markdown can be tricky and and it's not the it's, not the syntax itself. It's like a mindset when you're writing in in uh an environment, that's unfamiliar.

A

And confidence in in the final output is ultimately the anxiety that the root of all that anxiety, I think, is the lack of confidence that what you're writing will translate. uh You generally, no, I'm not trying to generalize.

C

A

But you know what I mean um so yeah anyway, that is, uh that is something that I'll hopefully be getting. You know.

C

A

On and feedback on uh in the coming weeks after the holidays and then uh hopefully implementing fairly rapidly after that, I think it's one of the larger opportunities we have for a group, and this is a good time to do it because of the setting. The focus on settings in nav has allowed us to maybe um slow down on like just strictly feature development.

A

In other categories, we can kind of tidy up the underlying editing engines, so you know so that we come out from the settings of nav work from the other side of that with a really strong foundation.

A

uh I think just the it's mentions in here, but uh for the record, I think probably what we would do is get this running in wiki first, because it's such a high uh highly requested feature, but a relatively low impact category for it to be implemented.

A

You know like if we disrupted all of issues, I feel like there's gonna, be a lot more edge cases when we introduce this in the mr description and issue description.

A

Wikis are fairly predictable in their content, at least wiki's written in markdown, and um certainly we would do like a phased and and.

C

A

Flagged rollout we're not just gonna, go live 100 by default, but I think wikis and and potentially snippets would be interesting areas to to explore and then clearly we want to apply this to the static site editor, but there's going to be actually a little more work to get that feature complete with the extensions we built on top of to um on top of the editor now so things like image, uploads it'll take a milestone or two to get a feature parity there.

A

So we just have to figure out when we want to invest in that time.

C

That sounds good. I think. Oh, that sounds really good and I was just curious on like potential area of first steps, and you know you covered that with the wiki as a potential one. So yeah.

A

C

Yeah, I agree with most of all that um I'll dig deeper into the canvas map post post time off.

A

Yeah, please do, let me know if you have any feedback and um yeah with that, we can wrap up. I'm keeping you all ready a couple minutes late, but I'll. Let you get on with it.

B

I always forget that this meeting is 40 minutes.

A

B

It's neither 30 nor 50. It's 40.

A

It's just I want to get specifically 40 minutes no well. I know uh this is this is a early morning for for you, michael, but um I don't want to interfere with your routine. So let you get your day started enjoy your last day before break.

B

Don't know well.

A

We all of us suckers have at least one more day.

B

Wait yeah. We are like okay. No, we have one one one. I was about to say.

A

Two yeah on friday yeah. I guess at this point the time zones have all shifted so that everybody in the company is on their last. Oh, has that most one more day before friends and family yeah.

B

All right, good job.

A

Thanks everyone.

B

Thank you, bye, take.

A

Care see you later.

B