GitLab Analyze:Product Analytics Team Meetings, 16 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Product Analytics - Building Live v1 Dashboards

Description

We built the upcoming product analytics dashboards for our first internal release in a classic dogfooding sense with the first version of the dashboard editor

A

A

A

I just need to find the right window where everything is running and working.

A

There we go, that's the one, no, that's, not the one.

A

This is the one good, so can everyone see your screen, I hope so looks like yeah.

A

Perfect, so what's the Agate of this meeting um I have, by now the dashboard designer working with saving to files and loading from files, which means that we can live edit, hopefully the dashboards that we are targeting for our first internal release and the ideas now to see if we can get this working with that editor and get the correct files and hopefully, at the end of the session, we have basically our two dashboard files in the visualization files that we can move over into the code repository.

A

And then we have our first dashboards created through the designer, and this should be working um in the document or I shared for our product analytics sync I shared also the schema changes issue, which is the main uh latest thing that Max has created, and then it's merged this week, which includes also all the schema changes to the database, table around sessions and daily users. So this is what we are running here um and on the other hand, we have also a short description: how the saving will work for all the people watching this.

A

Also, at a later point, that idea is quite simple: we save next to any group or project physically the ID to another project which then can have its own complete, separate settings of how it saves file, but it especially can be a different workflow than the project that you might.

B

A

Watching the dashboards in um and the same can go also for group, which is especially important for optimize, because they are rather targeting groups first and maybe at some point projects and we are going the other way around, which would then in reality right now. The everything that I will show today. Dashboard editor itself is completely generic, so it doesn't listen to anything, analytic specific.

A

We feed paths and functions from the outside and we would do the same for optimize and then it would also work there um and we are using the read repo API and we are using the right commit API. So those are the same apis that our web ID is using that the source code browser is using and as the other project, the dashboard repo um in that case is not having any sort of merge restrictions. We can directly merge into main for our first version.

A

The idea that I'm currently looking at for a phase 2 where we have then more, can also support more complex. One is not to create on every change in Mr, but rather that we can set it the dashboard Editor against a certain Branch.

A

So that you can set in the dashboard editor and in the dashboard viewing, though I don't want to build the dashboards of main I want to view the dashboards of this Branch, edit those save to that branch and then at one point basically say Okay I want to create an MR and match this together, which, in real ability in the dashboard editing, will be almost the same. Apart from one thing that will be basically dynamically based on uh which branch we are saving to.

A

But of course this will take another iteration or two until we would have that of opportunity. But.

B

A

Be able to support both kind of workflows along the line. um Questions around that.

C

Is the idea for phase two? Maybe this is a conversation for a later time to allow them to kind of permanently work off of multiple branches, or is it the point that they can kind of continue iterating on their dashboards until they're ready to merge it back into Main.

A

If you edit, as long until you are basically ready and say, I, would be happy to merge those changes now so you're, basically working on a branch all the time, because otherwise the the problem would be the workflow as soon as you say, I want to add a new widget and you click save, and if this would then go always to a new Branch or a new Mi, you would end up with tons of different branches and Mr. So.

C

Yeah I get I, get the idea behind batching it together. I think that makes sense, because, if you're working on like a a dashboard and you're trying to figure it out, but it's not ready yet, and you want to publish a second iteration of it.

C

If that makes sense, how does more specifically asking about whether you want to be able to allow users to always break off the branch like permanently that you know they can just change between versions of a dashboard while they're viewing one or, if it's just for that purpose of batching changes and then eventually, once they're happy with it? It goes back to main as like. This is the final version until I want.

A

To revise it again, I would rather say the second, but I would always leave it to the projects, because if you look at them of grafana setups Etc- and there is maybe simply the Restriction who can change what, but they don't have, they simply have a list of per dashboard per version of what versions are existing but I? Think if we, uh if we allow that, you simply can every anyone who is in a certain group.

A

Basically, the other project can edit and save directly to Main, and that company is happy with it and has simply a much faster workflow than great. But.

B

A

Be also able to support this additional workflow of huge chain to all your changes create a batch. The batch gets approved, gets into a normal merch request and then basically in menu will be see all those changes again.

C

Yeah yeah, just like just for context. The reason is I wonder if at some point we have to account for users who might start their set of changes, but don't realize that they're looking at an older version, because maybe.

B

C

As people or groups are working on, it main has changed and they don't realize that they're still looking at an older version of it but um yeah. We can that again, that's like getting into the detail of phase two but I'm just curious thanks, good.

A

Then should we should we try this out I'm I'm current, so what I have right now and my setup is the following: I have set up a second repo that I'm pointing in the source code as a hard-coded value at the moment, because this would then come from the backend and be configurable I have now that a project which is called company Dash XY, set Dash dashboards and under there I have a directory which is called dot gitlab for our config files, normally uh directory for dashboards and data directory or for product analytics and I have now the IDE open next to it, so that if something goes wrong, we can still fix it and we hopefully can also see all the changes.

A

While we are editing- and um apart from that, I would say, let's get started.

A

um What was our first one? The first one was always audience so I'm going in what you see here now is already that we have the two dashboards that are in our source code, so that the gitlit provided ones and those two are the ones that the user has created that are coming from the other repo that currently simply have an ID.

A

um So I'm clicking test audience that doesn't have any sort of widgets and they close also. My console bar.

B

A

And now we want to create a new widget which then gets saved into a different file so that we can basically reuse these multiple times across uh the the different types of dashboards and basically can feed options in it. But as long as we have a visualization, then we basically can change how it counts or what it displays Etc, but it would stay always the same across multiple Dodge dashboards. So looking at internal preview dashboard, our first one is users over time, so we have on one hand daily active user chart.

A

Currently we'll have only a line chart um and, let's take a look, so I have already the I'm adapting to the changes that uh Max made. So we have now here the unique users.

A

um What did we say per day? Okay, then? We also keep the point in.

B

A

Okay, the exit users. We want to group them by day, which is basically here we see now the preview on a daily basis. By the way, this is already pretty aggregated. That's why it's so fast. It's the all. The local queries take now under 20 milliseconds, most of the time, which is pretty nice, even if it's a limited data set, but just having something that responds so fast is perfect good. So that's our preview data that looks already nice.

A

We want to have a line chart which gives us this one here and we can take a look at the code that the whole designer produces. So this is basically unique user counts that looks good it's granularity day, UTC time and the options are also set so I'm fearful, but I will press add to dashboard.

A

So we are now going over.

A

C

I'm, making a note just to double check. Sorry uh daily users count the measure because I know in the issue: it's counting uh by Source, IP I, don't know. If that's the right metric I know we have Anonymous user ID, which I think this is. This measure is based off of, but I'm just gonna confirm that.

D

For that widget is there a way on the x-axis to hide the the average or the max, or even just that, num? um That line entirely.

A

Not yet, but that's exactly where we need uh what I figured out to the whole process is that we definitely what we need is um I call them inspectors so that we have in reality like a a file. What we want to configure and based in the configuration configuration we can set, what type of UI control we will have for this, so this will would basically mean show Legends check box and that, basically, is in the visualization designer.

A

We can then have those chart options which is currently an empty list in the next iteration, where we then would be able for the whole visualization to set and type that Legend, and that would be happening then, for that.

D

Good cool yeah because I think it's fine for daily active users to have average and Max, but it might make less sense for other types of widgets yeah.

A

Dude I hit save, it was saved successfully, let's not trust the system and reload and it works. The dashboard has saved that widget, so very cool best audience. So this is now the other repo and there it is it's not pretty fine. Yet that's also some things that I'm always copying in to my predefinite and back, but it's there good next one. What do we have next edit? Yes, we want sessions.

D

A

Sessions over time, okay, new widget sessions over time.

A

This is down here similar.

D

Over a daily daily.

A

I have here also already the different numbers in that mixes provided with duration, average per user and visit percentage, but we will take simply the total count. This is now one count we want to have this. Also, on a daily basis, I asked you yeah.

C

I think we just keep it consistent. Yeah.

A

C

A

A

We have a title head to dashboard.

A

Sessions over time.

A

B

A

uh What's next, in addition to the widgets above at the below widgets to the dashboard single step, total unique users?

A

Okay, let's try that did I had hit save already I I hit, save okay, new widgets, uh totally unique users which is discount, and now we are not setting anything but I will simply say single statistic, which is this one? So then we basically see the single stat.

A

uh We have the code now we need to add a title, so you need users.

A

Add to dashboard there we go.

A

B

A

Hit save, but by the way here the the visualization gets like a default title. That's what we are entering in the visualization and the first thing that you can edit now per dashboard is that you could, for example, this widget could then have different input options again at a later point, but you at the moment you can at least change the title. So this is basically also live, updating and changeable. There yeah.

C

I think that'll be useful in the single step too, when we start to want to show like Deltas relative to the total value or something like that.

A

um Good save and you widget. What else do we have.

C

A

Users, new versus returning sessions- oh that's a percentage, that's a calculation that we need to do, but we have at least we should have the repeat: visit percentage.

C

That would work for now.

D

C

D

Does that represent? What does this repeat percentage mean.

A

The amount of users that have returned compared to new users. There is a let's see what uh there is a. We can look at the code, which is called repeat percent and if you look at this month, request from.

A

From Max, then you can take a look at the sessions table and 10 percent of repeat session is the repeat count versus the count enter repeat count.

C

A

C

Tracking, whether there is a previous session before it, which is the which qualifies as a session as a repeat, yeah yeah,.

D

Okay, yeah, so that'll match pretty well with what the the new user's definition is. There then.

C

Yeah we just wouldn't be. We don't can't show both at the moment right now, but.

A

And there we, for example, we need an option. Should we round.

D

C

A

um So this is new users percentage.

C

I think it's returning users percentage, but.

A

Yeah I mean like this.

C

I I understood the the value to be for returning users like how many people returning our returning sessions.

A

A

A

B

B

A

It's polish.

B

A

And we hit save and total.

B

Number of sessions.

A

New widget session all sessions compared singers that.

A

Total sessions.

A

B

A

To you, my return number.

C

Is might have gone to edit before the save finished, perhaps yeah.

A

But good that we have a separation of widgets and visualizations, so we can say new wrong button.

B

C

I, don't think you hit save before you went back to editing. Oh, we are lost good.

A

So we have what what um returning users percentage.

D

Oh, that's cool, so it saves it under your recent under uh the widget had saved, but the dashboard configuration had not saved there. Okay.

A

Yeah exactly the visualizations as it's always separated is safe there and the other thing was the total sessions.

A

We need, uh do you really want to leave the page before uh you? uh Can you lose your unsafe.

C

Yeah I need some tests and some user feedback.

A

Average session duration open question: can we compute this? Yes, it computes.

C

uh Yeah we we have it calculated already as a measure average.

A

Session duration, let.

C

Me just say what I've noticed is that Cube likes to round aggressively down so I have to double check that.

A

B

Senior statistic.

A

And to dashboard.

A

Not safe again, thank you.

A

It's most of the time, it's the fault of the user. We know that already.

B

A

But that's also an interesting one. What do we do if the title make it smaller, yeah, yeah, I.

C

Mean that happens sometimes in, for example, size sense, where your labels might uh force your values to rap or something like that. But we can take.

D

A look I mean at some point. We could even go as far as to let each of the visualizations have control over fonts font size. At that point you become a dashboard designer and it's all up to you. If you really want.

A

And what we can do now for now is simply that we take this.

C

This yeah in total there's a five um single stats. Interspects uh I think they get a little bit more room to the labels.

A

Yeah, let's do this when it's polishing well.

C

There's that there's one more but.

A

That gets the full with number of sessions per user.

C

Or average sessions three years I believe actually that's the value that I'm not super keen on with Cube.

D

Because it runs it down, you mean or something yeah.

C

Like uh there's a, for example, I was calculating it based on uh test data set. Excuse me where it was a average of 1.4 sessions per user, but then it just showed one. um In that case, I was like that doesn't help. It looks like it's better here, but I'm curious, depending on the data set. If it's uh that value becomes a little bit less valuable. If that makes sense,.

A

Good, then, that.

B

Will be that's now, an interesting one. Let's.

A

See if we are able to build this one I've, never built that one. um We say new Richard, the.

C

A

Yeah yeah, so we have.

A

I think we only can sure one of the values either sessions are unique users. What do you want to see.

C

I believe it's you.

D

Know, oh I see uh we can combine those into a single table. Then.

A

Not not yet no, we can't show two.

C

Let's say unique users to start, then yeah I.

B

Guess we'll get both in.

A

And we have browser there, you go.

A

This means we have Chrome, we have the versions that would be good to have a sorting thingy and we have the unique users count.

D

And we don't have a way to update the column names there right now correct like for just the visualization. We couldn't rename that to like browser instead of QA UA family yeah,.

A

No not yet that's also a really good question. If we should do this fully automatically or do it fully automatically and provide still the option to tweak that afterwards, it was filled so yeah.

C

We can definitely clean up some of the names in there because, like I think like the Jitsu you need count is something that shows up yeah um and but then yeah still giving them customizability on the column names as well as like sizing, and things like that, which I think was probably brought up in a previous discussion, because uh perhaps your url or dock path field is, like you know, taking up 20 where it should be taking up the majority of the space right.

D

And a small knit on the title for this: it should be users per browser right, not browsers per user.

A

Yeah that that was made on purpose.

C

Making sure you're paying attention.

D

Play both in one table, what do you all think about just displaying two tables here.

C

D

B

C

I think it's more of a can. We can we add additional measures. I mean I, think it's more of just like enhancing the the widget itself to the visualization itself to support it, but.

D

A

Right, let me reload.

A

Hey root doesn't want to be saved browsers per users. Let's see.

A

Okay to Pro user, no sessions per browser sessions, browser slash students or Chrome yeah. You want to date the table. We add it to the dashboard.

A

B

A

C

B

C

Needs to be rearranged and uh and such yeah.

A

It's safe, I think so just to be extra sure good. Then we.

C

Have Behavior so Sam? Are you keen on having two tables now or because I remember? That was a concern from before.

D

um I wanted to see what it would look like, um I think it's good to have the information there. I do think it's a little bit busy after seeing it, uh but I figure for the the purposes of this meeting, we're just trying to get through to a first version. Some.

B

C

D

I think we might be able to try is if we want to do like one of the tables on the left, half and the other table on the right half. Maybe that would fit um or we could just ask some people hey. Do you think this is too.

B

D

Is this helpful and we can iterate an update from there.

C

Okay yeah because I mean I. Remember when we were discussing the requirements for this, we only wanted to choose one table all right and avoid using tabs, because we didn't support that and not avoid using multiple tables, because it was a bit busy but yeah we can discuss it.

D

To make make there be a single set there, what if we moved the three session related single steps down into their own row and then that would take up enough space of the sessions move down. It's like average session duration, total sessions, Beyond third row. What yeah there you go um with the average sessions per user, then the the table shouldn't try.

A

Yeah, do you mean this one.

C

No he's just like uh placing it temporarily, so the table can go next in line with the other table.

C

Yeah, like that and.

B

D

Get up again, no, we can leave those all in the same row.

B

A

B

Since they're all.

D

A

About sessions.

D

It makes sense to have them in the same row. uh The ideal situation would be to have all five of those in a single row, but we can't make that fit right now because of the super long decibels.

C

I would say that's more of a like: we should try to stick to the design that we originally intended for and then we get we have to fix the like polish, the widgets uh so that they don't.

B

C

Know wrap as or you know, display the values as long as they do right, I mean if we're trying to fit it to the requirement of the issue. Yeah.

A

C

B

A

It's displays now I mean we will as every time we look at this. We will be rewinded anyhow that we need to polish the rounding and we need to figure out how to show two different types of values per data set. So I don't know, as you wish.

D

So I mean I I'm finding where we end up hitting safe. Today it looks like this and then before we actually close the issue we get another issue put together about make the decimal rounding correct and move the single stats around so that it looks like the concept diagram uh before we actually officially close. It.

A

C

I, don't know that it necessarily requires an issue, because another issue, just I, mean specifically for the the visual bugs with the visualizations. Yes, but as far as the existing issue is concerned, it doesn't match it so I don't think we need another issue to like relocate the single stats. If that makes sense,.

D

Yeah this is uh this looks good.

A

um Behavior here we come should contain two widgets page views over time, so we will that's. Definitely we need to figure out a way then how to organize those visualizations, because of course they will show up everywhere um and need to have nice titles Etc, so um page views all pages.

A

We want to have them grouped by day, I. Believe.

D

uh We didn't call it out, but yeah. Let's do day good.

A

And we want to have a line chart there. We go page.

A

On the weekend that we tried to do a speech run with this.

A

uh Events over time, they are currently the same because page views are also evenings. Yeah.

C

But we'll be adding Uh custom events next week, so we can just build it out. It should just look different later.

A

um You've been all events, but they.

B

A

What we could do is.

A

No that doesn't work yet.

C

No I think yeah just simply advancing that as we collect additional ones. Yeah.

A

Because we could say on with a filter all events which are not page views, but there.

D

Is no scenario, that'd be a different sort of widget yeah, so I yeah. So this will be the all events and then we'd have that not page View events.

D

um If we get to the point of being able to show multiple series on this series of data on the same widget, that could also become multiple lines on a single line. Chart where one is one line is Page views. One line is Click beat clicks, one line is ETC yeah.

D

We don't have any instrumentation, that's doing anything besides page views right now, correct.

C

Right, we wanted to add a search, input, usage and uh I. Think breadcrumb clicks or something like that for the internal handbook, but that's not been added yet I have to create the issues for that. Okay, cool.

A

Doesn't seem to save those on the behavior one, which is interesting.

A

Page views over time.

B

A

A

Looks in general, fun.

A

A

That we need to figure out events over time. We also need to check if we make our row head a little bit smaller. Look at this I mean this is a huge gem between one row and the other row might be also something between two.

C

Yeah we haven't really messed uh or played with the grid stack configuration I mean this is probably the first time we've put all the widgets together, so we can take a. We can tweak to see. What's going to be ideal in terms of the spacing.

A

Huge events over time singles that total page views page views all pages single statistic.

A

B

C

A

Let's create first all the widgets and then totally events.

A

A

Single statistic.

A

Called the events.

A

And we hit save.

A

And then we want to show top pages.

A

Let's see new widgets page views.

D

Or average time on page is the third single step. If we can do that, one.

A

Yeah, that's currently.

C

A

C

Yeah really high tracking average session duration, I think.

A

um Good should we do URLs or paths paths, I, believe yeah yeah. Let's.

D

A

This is now an interesting one because we have also at least in my test data, but it will be different on the website. We have also track gitlab URLs internally with Chris monkey, so this is not actually a URL of the internal handbook, but rather the.

C

um You can filter by uh docos, though, can't we.

A

C

Let's say you host, but that's a good point: I mean. Ideally you wouldn't be tracking multiple Properties.

B

C

uh Root URLs, but.

A

You can say page path, add a filter on host which equals this one save and exploded. But.

B

C

A

C

Theoretically, it should work right if.

A

C

Should work exactly yeah, but.

A

B

Can just leave it, as is yeah.

A

We have the data table, so we will call this top pages.

A

And to dashboard.

C

And see who gets the most space? Yeah, that's uh yeah,.

A

That will be saved.

C

A

Let's see if it actually saved now, that's weird I need to check that.

A

Events over time save.

D

Refresh and set it saved successfully and.

A

Yeah, it's weird because the commit happened, let's see, what's in the file test, Behavior.

C

As the test, perhaps actually showing up sooner than the commit API is completed, it's yeah, maybe operation.

D

Because it has events over time in the file right there, yeah.

A

Zero six size, six five.

A

Yeah, maybe there's a delay.

C

A

C

It completes the commit, but it hasn't actually reflected or.

A

Yeah yeah cash bust Maybe good. What was the other top pages I.

C

Wasn't sure if it's caching, because it saved the new single stat for like it, lost a single line, chart I'm just talking about the.

B

A

Pages is in 6 0 with 12 K4.

A

A

That is it's some sort of caching. Also, that's.

B

A

Saving correctly, it's not simply, it's simply not loading correctly good, complete.

D

I think so, yeah.

C

There's a couple follow-ups for Behavior first and making sure we get the custom events and then um average time on pages, but I'll create these for this cool yeah. It's looking good.

D

Yeah, pretty cool and Tim is this being built off of the the Mr that you have posted for widget designer right now, or is this a different set of code that you're working off of this.

A

Is the spike so I have an MR, which is the spike which already contains exactly what's here and I'm, now, basically cutting away one Mr at the time to get actually fully merged um and right now what is basically being prepared is the widget designer which is everything in this page.

A

But without the filters and without um specific date, ranges everything else will get merged in this huge Mr and from that huge Mr, we can then definitely have much smaller ones and the editing experience um I discussed yesterday on today, with uh Brandon Ezekiel and Pavel from Optimus. So um Ezekiel has just merged today, the optimized component, which basically encapsulates all the VSM stuff in itself, and so you basically hand the component, a group, a project, and it will tell you all the VSM statistics of that project.

A

So the idea is to build for them use this dashboard designer, which is all the functionality around moving the boxes and saving it to a file and I will work together from Monday on the physical to get the Mr for this ready. So this will be basically, we can have a SQL working on this right in the specs and helping me on that, so that we get that over the Finishing Line and as soon as this is merged.

A

Generic dashboard component basically has then the capability to edit and save somewhere the main thing that we need to get rolling now on the backend side, if we are moving forward. In my perspective, this looks really good with this project pointer, then we just need the backend to provide us a field on a project in the field on group for optimize, where we can save basically the reference to that other project and build the UI around it.

B

D

Yeah very cool and.

B

And there's no reason.

D

I couldn't point it at my own project like you, couldn't there'd, be no, nothing stopping you from having the dashboards live in the same project that.

A

D

Definitions have been.

A

But most probably you will stumble across, especially in this first iteration, because this keeps us moving in the sense of that we can actually save files uh will be most probably than read and write access checks that you need can't post to main, which normally is the theme yeah.

A

But it's the nice thing is that we have now either or- and that's that means that we are already up par with grafana. Is you can go in any of those files and basically go into the history?

A

Wait until the webpack is compiled and basically have all the updates and would be possible to jump back to one of those yeah which is exactly one-to-one? What what grafana and not.

D

Even this is going to be a killer feature for our offering versus what a lot of other offerings in the market have. This.

B

D

A huge pain, Point many people just have to deal with and have no solution for it yeah. So.

A

That's all because we are using one percent 100, simply other projects exactly.

C

It'll, be nice too, to be able to um I guess, as we bundle changes and kind of reduce the amount of Mrs per individual change right by doing the branches like saving each branch merge as an iteration, so you can compare from like what's changed in the dashboard like I, don't know if that's worth exploring. Does that make sense like actually like the.

A

C

History of the dashboard itself and like.

B

C

To see what that, what that you just load, that version of the the configuration, so you can compare yeah.

D

C

D

To roll back uh preview.

C

Yeah yeah, it makes sense because, if you're, if you're, already like, if I built, One dashboard but I want to iterate over it, and then you know, 10 changes later I have version. Two then I want to see like what's changed since then, um or if I want to look back to see you know, maybe I did something wrong or I just need to compare it, because that's something I found I was doing often with size ends, but I had to.

A

C

Copying it exactly and then looking at two different screens together, yeah.

A

And if you, um this is the code for this and foreign.

A

What you have here is now this product analytics API, which simply has now here this hard-coded project value, and then it has hard-coded also the path to product analytics, visualizations and product analysis dashboards. This we could make this also configurable in the first iteration at a later point. But the main thing is here that I'm using simply here main right now, also as a static, which means, if we have a switcher at the top, we could switch to any kind of Branch or commit to load from there and yeah this. This would be really nice.

A

Yeah shouldn't be hard, because this is just yeah one, one, one value that needs to be fed into that function, rather than use main all the time.

C

I've got a lot of uh I. Think I have like 14 issues to create, based on this meeting.

C

um Also just before I forget Tim uh debalancing, on like things like editing, widget titles. Do you think that's something we need to look into just because like when you're typing in live the title: okay, yeah, because I imagine 10 widgets in you know that might have.

A

Some issues this is currently not even debouncing. This is even just in the view component, basically updating the object, all right exactly.

A

C

And I'm not I'm, not saying that should have been there. I just I want to make sure like in terms of follow-ups, just kind of came up as an.

A

C

I'll create a follow-up for that, so.

A

We will tune out those two paths. One is that already in review huge first iteration for the widget designer the other one is that we cut out the first version of editable dashboards um and then the follow-up would would be adding um the filter adding more inspector stuff so that we can really go deep into such topics like hiding the legend perfect, perfect first example, so that the component basically gets an option. We get a config file which says yeah line. Charts can I will have an option.

A

It says Legend on off, which has a which has a checkbox and then because otherwise we will building constantly huge view components. We need a. We need a system to have configurable UI in that sense, so.

C

That's fine yeah. We have, like all the options. Sorry go ahead.

A

Yeah that we can build stuff really fast next to each other, for especially such static types, but also they'll, have a good example is for optimize. They will not. You need a widget designer at the beginning. They will have one component, but they need to set in the dashboard for this component, always the project that this component should display um and and that's something we should also generalize from the get-go so that we have like an inspector which can say it's a Boolean or it's a project selector. So.

B

D

A

Hopefully, if they're going.

D

To be using, this they'd be willing to contribute back some of the features that we both need around. This is what display and widgets looks like, because uh we have lots of very specific questions about our underlying data sets and what we need to do to Define how a session looks or a returning user, but things about how do I turn on and off a legend.

D

That's generic from product analytics and more specific to front end, so I'm excited we'll be able to solicit contributions from other people using this and eventually we'll get that that flywheel of lots of groups use it. So lots of groups contribute some more groups, use it and you know so on and so forth.

B

C

Yeah for now, I have a couple uh of follow-up issues, just specifically for what we need out of the the widgets for the internal preview, but I think it'll be useful to go through each uh visualization, so, for example, line chart and see what options are presented by e-charts, for example, and what we exposed to gitlab, UI and then yeah uh identifying which of those we just have as standard controls. You can modify in the uh the the visualization designer itself.

A

C

A

So in reality, I can take now these files take them into the source code and replace the the test dashboards that we had so far and basically use them and delivered them straight away. So as soon as we have the connection of production and have this super special Mr with those updated dashboards, we should be able to see exactly those dashboards that in production next.

D

Week, yeah pretty cool, that's.

C

A

Thanks a lot thanks, a lot again for being super flexible to move this to Friday and then Happy rest of your Friday see you soon send enjoy your holidays as you are off.

D

From today, thanks I might be able to join for the holiday party, but otherwise yeah I'll uh I'll see you next year, um afterwards, yeah.

C

Perfect well, there's a fun phrase. See you next year, bye.

B

B