Grafana UX Squad, 1 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Grafana UX Community Call 2021-03-01

Description

Meeting doc: https://docs.google.com/document/d/1Qq19Yr0tK0LNcm5cKpQnuMmZovXnjGgtuA1oze9e23s/edit

If you want to take part in future user interviews: https://grafana.optimalworkshop.com/questions/help-us

GitHub issue discussed in call: https://github.com/grafana/grafana/issues/3163

A

All right and to the cloud.

B

Looks good all right.

A

B

So I see we have one more joiner, hello, mikhail. I don't know how to pronounce this the right way, but hello, um so I don't know. Should I just start.

A

From the top, or when do I start? No, I think we can start from like research, query, editors and just take it from there like yeah this whole technical hiccup is just let's put it behind us and just move on. I mean this is live tv right, yeah.

B

A

Much so yeah, but I think.

B

What's important.

A

Is that um the next community call is not the first monday of april, it's april 12th from what you said so far um and I think yeah you can reach us on grafana grifona fails on slack and today is about elastic search, raw query, editors, yeah and if you have feedback comments, feel free to comment. Asynchronously and just I think stage is yours.

B

Thank you yeah, so we have not looked super specifically into elasticsearch so far, but we have run general research on how people use our query builders and what they are looking for in a query builder. So I wanted to share these research results with you, and maybe you have additions and comments to your specific experience about elastic that can enrich our our research results that we already have and thank you good point.

B

I was about to forget to share the presentation that would have been bad uh right, so some facts about our research that we ran. So we had a survey about query editors and from that survey we were able to get two community volunteers and then also we interviewed four of our own team members.

B

So we had six user interviews about query editors and if you want to see like what kind of users those where and what their experience was, so 78 of them were long-time graffana users, so quite proficient users and they all had prometheus as their most used data source.

B

This is, of course, a bit unfortunate because it doesn't cover the elastic use case super well, but that's exactly where we're having this call right to learn more, and maybe you can tell us some similarities or equal usage patterns that also apply to you, we'll see curious to hear more so our users that we surveyed and interviewed used query editors equally in explore in the panel edit.

B

Some preferred explorer some preferred the panel at it, and then we also had people who use both equally and in the end like it just distributes to the same amounts of people. That's very interesting, so I guess we have just all kinds of experts out there for querying stuff and also we asked people how they felt about our query, editors. What the experience was like we had some users who said they really enjoyed it.

B

The majority said: either it's pretty good over 30 or it's doing the job okay over 30, and then we also had like almost a third saying: it's not that great, but we also had I hate it as an option and no one said that. So that's something then again. If people really hated it, probably they aren't using grafana anymore, so they wouldn't be contributing to the survey, or at least I presume, that's how it would be so yeah. We can see from these results that there is definite improvement potential.

B

So we ask these users what are must haves for them for a query editor, the biggest issues that they had were auto suggestions and auto, complete also that the query editor be easy to understand, even without a manual. So no one wants to read the docs in order to learn how to use a query editor. It should kind of work self-explanatory and naturally, most users wanted an option to switch between a visual query, editor and a raw code. Editor, I mean that's the github issue that sparked this call right.

B

That's kind of the same need also users wanted the query editors to cover as many features of the query language as possible.

B

That's also where the option to switch between visual and code comes in handy because, usually the visual query editors has limits of what they can actually do in terms of complexity, and then people really wanted the query.

B

Editors to be optimized for keyboard usage, especially the power users really like tabbing through their queries and not clicking around too much and an example quote from the interviews was I like a combination of visual that covers the most frequently built queries and a text based one, that's quick to edit with great tab, completion support that does not get in the way and this tab. Completion support that does not get in the way already implies that that is something that maybe grafana is not doing the best at at least for prometheus.

B

That was one of the biggest complaints with auto, complete um and also yeah, auto suggestion. So users have said, for example, that the tab completion is sluggish. It takes a while before suggestions load or they don't load at all and also in explore. Specifically, it seems that the autocomplete gets in the way more than it helps since we ran this research, I think a couple of months ago, and I have already relayed the feedback to the team.

B

I'm pretty sure that a lot of prometheus team members are already working on this stuff because of course, that's not great feedback, and we want to improve that. But if you have similar experience about a different query, editor or if these issues are something that happened to you back when we still had a raw code editor for elastic. Of course, we want to know this, so we can make it better. So users say that when they have a suggestion and they want to hit tab to select it and not use the arrow keys.

B

So like a lot of fine-grained usability feedback came out of this research and one feedback that we got about querying elasticsearch in grafana was that for the elastic query language, the hierarchy is missing in the grafana query editor and what the user said was right. Now you have to do the double work mentally when picking a field, because it works in a reverse way. From what you expect.

B

If I want a derivative, I would like to pick that first and then add the origin. So that's about the way that elastic data is structured and, at least from what this user said. Grafana doesn't represent that in the way that it's supposed to be or like the mental model that feels natural to elasticsearch users, but that was, I think, the only feedback that we got specifically about elastic so now would be a great point in time to hear more about this.

B

So I prepared some questions that maybe some of you have answers for so stuff like what are your needs in a good raw code, editor for queries in general, um but also specifically for the elastic use case. What did the previously available elastic raw editor do well like what do you want back, but also? um What can we do better in the raw code? Editor that the visual editor isn't doing for you like so many questions?

B

If you have answers to any of these feel free to jump into the discussion right away or add comments, asynchronously in the video or on slack or via email, anything goes. We want to hear it all.

A

Daniel or mikhail, do you have any experience on comments on that and what jess just showed.

C

No, unfortunately, I never worked with the elastic query. Editor.

D

Yes, a little bit so.

A

D

I don't suppose if you think back to like years ago, where um I know before grifon had had support for elasticsearch at all. um I know he was quite quite common to work with the jason blob um and then be able to copy and paste into integration later when added when it had support for raw query editor. But that's one thing that that got lost um you can't you can't easily copy and paste from from, um but the reason for losing that was, it was just so complicated on the grafana side.

D

What we're doing with time series is. uh It is like loads loads of nested things, so it just doesn't translate anymore. um I don't if anyone else has anything to add. I'm super a lot, a lot to say just on this.

B

So maybe follow-up question to that. I can imagine that copy pasting is super important, but what could other use cases for a raw code editor be apart from copy pasting? Is there anything that comes to mind, maybe geo for you as well.

D

So things like maths as well, um so there are uh or they're called you can do like these, uh um some things together and and to do sort of like more than more advanced things. We have like limited support for it in grafona, um but like won't, be able to do like more advanced versions of those. uh That's another.

E

D

F

There is another use case which uh I I find pretty frustrating, which is that it's impossible to reorder fields in the in the visual creator, meaning that, for example, if you're doing aggregation, they basically run one after the other, and sometimes you just want to add something before the last one and with the current creator you cannot really add something as a let's say, first position, which means you have to delete everything you have done uh until now and add what you need and then add back all the aggregations you you wanted, which sometimes kind of frustrating, because you have to remember what you had before and uh and whatnot.

F

uh I think like in this case a row creator would help uh like. Given that we are, I mean, let's say we are not implementing the reordering uh in the visual creator.

F

uh A royal text creator will help, because you will, you will have the the possibility to to do it manually at least.

B

I see that makes a lot of sense.

F

I mean I know there are people, for example, right now uh editing manually the panel json data to do that, because it will basically do the same thing but yeah.

B

But is that more tedious, because it's not specifically the elastic query language or like? Could that just solve that need or why would people still want the raw editor if they can just change the panel jason.

F

um I would say one of the reasons could be so elastic. Elasticsearch itself has a lot of huge features that we don't support, because they are slightly out of scope for grafana. Sometimes there are advantages case that that we don't explicitly explicitly support, but that that grafana could theoretically support.

F

So I guess people want to have this freedom of uh using elastic such features that we don't expect basically support in grafana, even though that might break uh the equity itself, because there is, as there was saying, there is a lot of magic going on under the hood.

B

Interesting so maybe coming back to raw code editors in general, maybe that's something that mika youth can say something about like. Is there anything that you generally think raw code? Editors need to do or need to have as a feature in order to work for you.

C

All data sources are different, I mean in my experience, whereas I was working in redis labs. I was working a lot with the radius data source and for that we have a different data types, and for that I had a special code editor as well, so where you can actually do the raw input. So I totally agree that it makes sense to head with code editor, especially you have you're already in grafana. You already have a code editor class right which allow you to change. Json json, so having this capability actually will improve.

C

uh You can add, with custom features right which is not available in visual editor. If there is a new version of elastic or any other data source will come out which is not supported at the visual, yet it can be you can you can edit right.

C

So in this case, you can use the newest feature of the data source itself, elastic any of them and when graffana will implement it in visual, it's great, but you already use it as a rock, and the copy paste is great as well, because sometimes and something can be changed in visual and, for example, some id type something changed.

C

But having this uh code editor actually will keep your rock query as it is. So I think it's actually it's a good feature for advanced leaders.

B

All right, thank you, so daniel rgu have you used the og raw query, editor that we used to have in elastic and like was it any good or if we thought about doing a raw query editor for elastic again, would we do it completely differently because it was years ago- and we can do it much better right now,.

F

I didn't actually use the old one I mean like. I used the the one before the current version, because the one that has had the raw query mode was what I think was like three years ago that we or four years ago that we stopped supporting it or maybe.

E

F

So I didn't really use it. uh I think that, with the current creator we can do, we can do a lot of things.

F

Like it's, it's it's cleaner to work with the new one that the previous one might be a bit biased, but I I think I I think it supports uh more use. Cases like in on a cut level.

E

It's easier to extend.

F

Now, I'm not sure whether, like all these flexibility should be really- I don't know, maybe exploited to to do things that that visual creator is not supposed to do. uh I I don't know where to put the boundary for the visual creator to uh to keep it simple. Maybe uh I don't know if I'd rather get a really like full row creator over the visual one or keep pushing new features in the individual one.

F

That's something.

B

That's a that's a great question like does anyone else have opinions about this question of where the visual query editor should consciously draw a line and say I'm not allowing this, because if you want to do it at this complexity level, then just do it in code or do you think that everything and anything should be covered by a visual editor, if possible,.

C

I agree: visuals have to allow you to do simple things, and so it won't be that complicated for users who just started to use data source for advanced users code editor is a good way to go, but visual have to be as easy as possible.

F

Yeah, for example,.

B

That means sorry geo. You first now.

F

Was just like uh adding twitter, I I was imagining like the elasticsearch creators. Elastic supports, like a ton of different kind of aggregations and options for each kind of aggregation, and I'm imagining like a new user uh using the elasticsearch creator and you know opening a drop down. Having like I don't know, 150 options to select from which are like, maybe like 99 of them are not even that common and almost I I don't want to say useless, but they're very you know very niche use. Use cases same.

F

I imagine, like those new users uh being overwhelmed with information for if they have a like a full-fledged uh visualizer with tons of tons of options. So I'd rather keep it simple like serving the the most common use cases. Let's say.

A

Yeah, I think, like what you said geo is extremely important, is like the question of where to draw a line, is most common use, cases for people and everything that is out of the scope of most common use. Cases like 80 20 uh should be raw query, editor yeah.

F

I mean like, for example, in ostriches.

A

You can do a full.

F

Text search- and you know adding scores on document buzz and based on on on on text, but at the end of the day we are graffana. It's it's. It's a you know, a time series visualization tool and we are now introducing logs and traces, so it doesn't really make sense to have. You know full really to have the full potential of search in in an elder that it's not supposed to do this kind of things. That's my point.

C

I don't really agree. I mean yes, grafana started as a visual tool. Now it supported locks and everything. But if you actually create your own custom panel and you're going to use a elastic data source, you can do whatever you want. Do the full search with the special panel. Add the data delete the data, so I'm looking at the platform as a application platform, rather than visualization tool like right now. So I mean everything, data source can provide is great right, but it should not be limited as a time series metrics anymore.

F

No, that's true. That's right. I agree with that. uh Like my my my point was on the the the 80 20 of use cases so like what to say is very true, but I think this is a some use case that would be solved by uh a row text editor.

F

Does it make sense.

C

Right right, I mean data source have to provide this data right access to that and the way how it's going to display there are so many custom panels lately community create. So let's give them the chance to implement what they're looking for right, then, the limiter yeah.

F

That's a good point. I think it's it's a very good point because yeah, where do we draw the limit, because this is a totally valid use case like someone would like to to have this kind of data and create realistic search?

F

So maybe it's a very it's a very niche feature or very nice use case, but should we support it explicitly? At least.

B

Yeah and like this is one of the things these edge cases are really hard to gauge how important they are without user feedback, and even if we get user feedback, we don't even know whether it's representative, if we have two users who say we really need this, but they are the only two users in the world who really need this, and we have no way of figuring that out right now right.

B

So currently, it's really hard for us to make these choices, and I guess we take a lot of educated guesses in making them, but the more user feedback we get about this stuff, the easier it will be. So I can only encourage users to take a good example from mikhail here and join these calls and talk to us.

C

It's my second call when I joined during previous one of this one, but when my question is: uh when are you working on with elastic data sources? Are you working with the elastic companies themselves because they're the one who knows I mean I'm working with radius labs? I know what our users are using right, what data types, what kind of queries, so they can actually provide this feedback, so it will be great to talk to someone in the last ticket themselves and that's them.

F

We have some contributors from from elastic uh which were helping us with the with the new version of the data source. We did a bigger factoring recently uh yeah, that's that's a good point. We can. We can probably gather some feedback directly from from them. Probably I mean because.

C

B

Considered great idea very good.

C

Right me working in the customer success, I know exactly what is twenty percent of the use cases we need to cover in radius, for example, so they should know that means you should find the right contact in elastic. Who can tell you this is.

G

What you need you can just proxy this information in a way, it'd be smart. The way we obtain it yeah.

C

Because it's really hard to support different data sources when you don't actually know how the users use it or how it was developed, and this kind of insight you can get from the company themselves.

F

Yeah, that's also true that I mean like elastic, has kibana as their own product, and I don't know if their opinion on on what user wants. It's like might be a little bit biased by what kibana offers like, I think, kibana and grafana offers two different are two not totally, but I are two fairly different products, so I wonder how biased uh a user of kibana would be using grafana in terms of what they expect from from an elastic search.

F

Query editor, but that's a good point. I mean that for sure could give like a lot of input on what we should support and what to look to at least.

E

That seems like a fairly uh basic question: do the people using the elastic data source want to have a query? Query editor in grafana that is basically the same or at least very similar to the one in elastic.

F

As far as you know, like I'm, not, I didn't talk to that many user. uh I'll be honest, but as far as as I know like the power powerful thing about kibana is that it really enables you to explore your data.

F

Yes, you don't have to to know the data beforehand uh in order to query it like given itself guides you through through your data through your indexes to to extract information.

F

uh That's why I think, are there two different use cases, but.

F

That's a good point.

B

But wouldn't some of those users potentially also be using grafana like the more advanced users? Maybe they need less guidance? I don't know. Maybe they still need that amount of guidance, but especially the not so advanced users they might profit from that. A lot like or how would you evaluate that like? How is the better exploring of kibana something that we could learn from for grafana.

F

I know for sure that some of that some of them some of the people, I know that that are elastic search users, who's both kibana and grafana, so it doesn't feel like there is something like they.

F

It doesn't doesn't feel like. They are competitors in this field, like I think people use them uh both.

E

F

To do different things so would.

E

Be nice maybe to ask those users.

F

uh What they use, why they use grafana for some tasks and why they use kibana for for their attacks.

F

E

I I don't, I don't know.

F

The answer here.

E

Yeah, like what are you doing when you're in the elastic stack versus when you're using elastic data in the grafana stack.

C

Combine only works with with elastic right as a data source yeah, nothing else. I have a used keyboard a long time ago, but I mean graphene is great because you can have an access to multiple data sources. At the same time, when you see your elastic cache, you can see metrics in kubernetes some somewhere else right. So this is the use case where you're going to use grafana for that compared to kibana.

C

But, but really actually have had a chance to look at kibana how they do that as a as a team before doing elastic search.

F

We, I think I I personally like use graphic a bit.

F

Like I'll be honest like when I uh like, using kibana, felt totally different for me, like.

F

I don't know it's like using grafana enables me to query my data as a as a user. That knows how his data is is stored, where how and and so on, well kibana felt sort of like an exploration tool for my data, but I'm not. I might not be the best user for for the this case, because I'm very used to grafana. So I know how to use grafana and not so much kibana could.

A

You elaborate a bit about this kibana uh having um feeling a bit like exploration tool.

F

uh Like the way, for example, you you, you create um a visualization on kibana, let's say uh everything starts from the usualization that you want to achieve more or less there's, not always the the truth, uh but it feels like there is a lot more um emphasis on the visualization you want to achieve, and then they will guide you picking the fields from your database.

F

So it's not like. I want to visualize a time series then give me those fields and they ask you for for fails to in order to visualize this time serious data, or these I don't know whatever other kind of visualization you want to have well in grafana, it's sort of different like I. I wouldn't even know how to explain that properly, but it sort of feels like I already know what I'm going to achieve.

F

So it's not there's. No one asking me, oh what kind of visualization you want to achieve. No, I already know what I'm doing and here's my here's. My query do that for me.

F

That was my my my feeling like comparing rafana and kibana, but again like I, I know grafana way more than kibbana, so I might not be the best user to compare them.

A

But it's fine, we want all the perspectives you want, we we can have.

B

I'm also curious because you described it that way, so do you feel like the focus on the visualization in kibana, is more of an extra hurdle that you don't need.

F

Yes, like I, I feel like that this this whole emphasis on on guiding the user on kibana is is sometimes overwhelming, like oh you're asking me for that for these these and then like midway through, you realize. Oh no, that's that's not the way I get these nice, these religious visualization, I saw the other day.

F

I don't know to me personally. Graffana feels more immediate. Like okay, I have this there's elasticsearch. I can have my.

E

F

I do my query and I will get a result that I was expecting.

F

Yeah, it's sort of.

B

F

I was always just thinking about like, if sort of feels to me that kibana sometimes it gets in the way, meaning that they control.

E

F

You you get your data.

B

F

B

I was gonna ask like because you said that sometimes you end up in kibana with a result or like halfway through you realize that the result is not what you were looking for and in grafana that's not a problem. So how do you actually decide what the right result is.

F

I would say in grafana I know the query I'm doing in kibana. The query you do is actually no, it's not really hidden, but it's secondary. Like grafana. It really has a lot of emphasis on the query itself, so you're building queries in grafana in kibana, you're, building, visualizations.

F

Which is actually very good like I I I like that idea of you know, building a visualization, not a query, because, like I'm exploring my data and let me play around and okay, I have some nice realization now for my data, which maybe sometimes I might not fully understand, because I don't know what I'm querying well in grafana, I know what I know the query, I'm doing, but not being an expert in I don't know, uh statistics or or whatever.

F

I might just you know, picking uh yeah having a visualization for a query which is not really descriptive. So you have, you know like pros and cons for both approaches.

B

Yeah, that's super interesting. I would love to hear from other people their thoughts about this and how they compare these two very different approaches to querying data, because I agree that grafana is focusing more on the actual query part. I mean you have a preset visualization there and I think 80 of our users just keep that preset time series graph and don't bother changing anything about it, because it's enough for them in order to see what their query does and that's all they need right.

B

So I'm really curious to to understand like what it is about querying then that leads them to their.

B

B

I'm looking at the questions here and then um because we still have a few minutes left and mikhail is also still here.

B

Maybe do you have any general feedback about query editors, anything like what is your favorite query editor, and why or what is the worst query editor that you have used and why, like? What can we learn for making better query editors in general.

C

I don't really have.

B

E

C

To listen more okay, but I mean it works works for me. Aquarius I mean. Is there any query? I can get what I need most of the time, so I'm good.

B

So maybe follow-up question just in general, michael, are you more of a keyboard querying person, or are you one like that likes clicking and picking stuff from drop downs.

C

I'm more visual guy, so it's easy because I mean when you want to explore the data as a when I started to work with data source right with anything. I don't know my options so for me it's easy to click around and then, when you're familiar with data source, you already know that you can go to directly with the query. Editor do some something uh some hiking right sort of thing, but visual is.

C

B

Cool interesting geo, what about you.

F

I would say actually the same, like I like to use my keyboard to use the creator uh when it's when it's visible uh or when, let's say when the editor itself supports keyboard navigation but yeah. I I try I like to to click around and to see what what I can. I can do.

F

I'm not that fan of these. You know like text editors, but I I I can see I can see their their their their strength compared to visual one, but I also like you know to click around and explore my way uh building a query.

B

And that's something that I find so interesting. So if I listen to you and then also the comments in the original github issue about this um geo, you mentioned, or you wouldn't want to replace the visual editor with a code editor, and I don't think anyone wants that. I think everyone would just like the best of both worlds right to have the visual exploration options and it more of an exploratory approach to querying.

B

But then sometimes, if you just want to copy paste something or if you already exactly know what you want to do, then it can be faster to do it in code. Instead of having to do lots of clicking right.

F

C

Right, it's like what you get is what you see approach when you can have this visual approach. When you configure what you want right, visual and then you have a second tab or immediate. You can switch to code editor. Even sometimes I feel that maybe it's not one to one right. You cannot switch to from visual to code directly, maybe just start from scratch from code or just get with the template, but like immediate switching from one mode to another. One will be great if it's possible.

C

That makes sense.

B

Yeah yeah, I think that's one of the things everyone in the research like regardless of the data source, that in an ideal world, they would love to have this one-to-one connection between visual and code and the option to switch back with no limits.

B

But if it only was that easy right, it's so hard to build that on a technical side. So we I think it's not realistic- that we're gonna be able to do that anytime soon, but uh yeah. I guess it also depends on the complexity of the queries. So we'll see we'll see.

B

All right any more questions from you, because theoretically I mean we lost a bit of time due to the technical hiccup. But theoretically the call is over now so.

C

Don't have anything new you're working right now, so you can show us what's coming for india, fina 8, for example,.

B

Oh, we have so many things that we're working on right now, but I don't think I can show anything concrete geo. Do you have anything.

E

uh I don't know about showing, but I think that the oss road map has been posted publicly. um If it hasn't been, then it will be soon. Maybe we can link that in the youtube comments uh when this is posted.

B

Will do absolutely.

E

Yeah 7.5, however, is going to be coming in march, and so that is coming uh very soon. um I don't have the list of features yet, but keep posted. The beta should be posted very very soon.

C

Okay, thank you.

B

And one feature that is going to be released in grafana 7.5 as like an mvp beta version is reusable panels.

B

So that's not very related to query editors, but it will enable you to use one panel in multiple places instead of having to make copies every time. So that could be interesting. If that's something that is a pain point for you,.

E

Yeah themes, one of the major themes for uh for 8.0 is dashboard management and so that reusable panels is going to be a big part of it. If you want to have an effect on how the end result looks, then you definitely want to get involved in testing the beta and providing feedback, because we do take a lot of guidance from user feedback.

C

Thank you. Do you have anything special for streaming capabilities.

E

If you mean the uh streaming data sources, uh yes actually, but uh I I'm afraid I can't go into too much detail there, because I haven't written the documentation for it. Yet so that's how I learn about things. I write the docs, but.

D

E

Actually, one of the major things that we're leaning into.

C

Okay, because I tried new time series panel, which works much faster and better than the ground before there is a special dot which so I'll show you that it's actually streaming data source, which is great, but uh I mean- but I talked uh there- is only one streaming data source like uh six months ago, seven months ago, and not a lot was done recently with streaming data source. Maybe it's not a scene yet, because I think it's great to have a string streaming data source which can stream data in real time.

E

Yeah, I believe that, right now it is either part of the grafana data source or the test data db data source, and you can actually I'm pretty sure it's test data db, like I said the docs for that haven't been written yet because they're, it's so so much early days, but I think you can hook a data source into the test. Dd tits data db streaming uh right now, but yeah there will be a more fleshed out and finished version of that coming soon.

E

I want to say for 8.0, but you know right right now: the 8.0 roadmap is still pretty general and we're trying to see how much stuff we can cram into that and you and uh there will be a lot more deep, dives and announcements in grafonicon when we get around to that. To that event,.

E

Okay, thank you. You're welcome.

B

All right cool, so I think we have discussed all the questions also. We have run out of time. So thank you all for your time or for watching if you're watching this later and we're hoping to hear from you and see you again next time. Remember. The next ux community call is on april 12th as an exception. It's a monday, but not the first monday. um Yeah, hopefully see you around and who knows, maybe by then we will also have something to show from the upcoming grafana 8 release.

B

I don't want to promise too much, though I don't know yet. We haven't made plans, but we'll see you can check the agenda in the meantime and see when we come up with anything or follow us on twitter and get updates about upcoming community calls in the meantime, stay safe, stay healthy and have a good rest of your match.

C

Thank you. Thank you.

C