►
From YouTube: Grafana UX Feedback Session 2021-09-08
Description
In this session we saw some ideas for our query editor redesign and got updates on transformations. We do this (almost) every Wednesday, so tune in to our channel towards the end of each week for some UX wisdom!
B
C
E
E
E
It's
fine,
so
I
think
today
we
have
patrick,
is
partner
here,
yes,
patrick's
there
cool
and
he
is
going
to
talk
about
bigquery,
though
he's
going
to
give
a
query
builder
demo,
which
will
be
part
of
also
next
week's
community
call,
and
he
would
like
general
general
thoughts,
all
right,
general
thoughts
coming
yup.
Take
it
away.
F
So
yeah,
so
I'm
just
going
to
sort
of
show
different
parts
here
and
we'll
have
to
give
you
thoughts,
then.
So
the
basic
idea
is
that
we're
basically
having
connected
inputs
instead
of
the
way
it
works
today.
So
if
I
would
take,
for
instance,
I
would
use
influx
tv
here
as
an
example,
and
I
would
have
at
everywhere
here
so
then
I
would
pick
cpu
and
then
I
would
get
this
thing
here
where
I
can
then
change
these
if
I
want
to.
F
F
And
this
here
would
work
in
a
similar
way,
so
I
can
maybe
take
a
selector
here
for
this
and
they
cannot
see
usb
remote
again
and
then
I
can
pick
a
transformation,
and
here
I
have
this
sort
of
so
the
difference
here
is
that
with
the
last
one
here,
I
can't
change
this
thing
here
and
I
think
in
the
dark
name,
is
sort
of
subtle
when
it's
disabled
background
or
interactive
background.
But
as
you
can
see
here,
you
get
some
sort
of
hoover
effect
that
it
should
tell
you.
A
F
H
F
A
One
thing
and
sorry
I
will
I
will
pop
this
into
the
into
the
into
the
the
docs.
I
wonder
if
there's
an
accommodation
in
this,
this
type
of
layout,
to
either
just
state
without
being
able
to
change
it,
like
the
the
other,
only
called
the
the
operation
between
those
two
like
those
two,
those
two
fields
that
you've
added.
Is
that,
like
an
is
that
and
or
is
that
or
or
like
do
you
know
what
yeah.
F
F
Good
question,
because
there
are
other
situations
where
we
actually
have
these
situations,
where
you
can
sort
of
pick
and
or
or
between,
because
this
one
data
sorting
enterprise,
where
you
can
sort
of
have
a
group
that
you
sort
of
put
in
parenthesis.
So
you
have
like
two
groups
that
you
can
and
or
and
yeah.
I
haven't
really
figured
that
so
that's
sort
of
the
next
step,
because
that
is
sort
of
a
more
complex
thing.
I
would
say
I
can
sort
of
share
a
bit
from
as
I'm
working
on
a
presentation
for
this.
So.
A
F
Yeah,
so
they
basically
here,
you
have
some
variation
on
how
it
could
work.
You
can
also
have
it's
not
situation,
you
might
have
multiple
values.
So
then
you
can
have
like
the
most
select
thing.
Also
going
on
and
the
idea
is.
It
should
be
quite
clear
like
what
you
can
interact
with
and
what
you
can't
interact
with,
which
I
think
is
sort
of
the
important
part.
F
F
I
Any
other
thoughts,
I
think
this
looks
really
good
in
general.
One
comment
would
be:
if
you
go
back
to
the
influx
db1,
I
I
think
there's
pro
pros
and
cons,
I
don't
know
where,
where
I
mean,
because
one
thing
that
has
changed
here
is
that
yeah
all
these
options,
time
zone
order
or
the
buy
limit
as
limit.
I
think
those
three
are
kind
of
options
that
are
not
visible.
I
Currently,
there
are
kind
of
options
that
you
can
optionally
add
by
by
hitting
the
plus,
I
think,
and-
and
so
this
is
my
theory
is
one
thing
that
I
think
is
good
with.
That
is
that
we
don't
overwhelm
users
with
optional
options,
and
here
all
the
optional
options
are
visible,
which
is
good
for
discoverability
and
for
kind
of
yeah,
for
for
the
user
to
know
that
these
options
exist
but
yeah.
So
that's
the
pros
and
cons
there
that
I
don't
know
where
what
what
the
optimal
kind
of
solution
is
for,
like
showing.
J
E
I've
got
a
comment
for
the
optional
options.
If
we
can
hide
them,
I
think
that
would
be
good
mostly
because
I
don't
think
we
need
to
do.
We
need
to
do
extra
work
to
make
things
discoverable,
because
someone
who's
using
influx.
They
will
already
know
some
of
the
influx
features
and
then
they're
happy
to
look
for
them
and
I
would
sort
of
argue
the
the
rarer
case
is
that
someone
who's
never
used
inflex
before
comes
to
influx.
Somehow
data
ended
up
in
there
and
then
he's
trying
to
figure
out.
E
A
I
think
I
agree
with
you
for
griffana
currently
when,
when
I
hear
about
grafana
wanting
to
be
more
adapted
to
like
bi
use
cases,
that's
when
I
start
to
think
about.
Oh
okay,
maybe
these
people
making
these
queries.
You
really
only
make
a
query
like
yeah.
Maybe
maybe
I'm
just
wrong,
but
I
think
when
we
start
talking
about
those
bi
things,
we
start
getting.
Oh,
maybe
maybe
that's
less
so
yeah,
no.
E
E
I've
got
another
comment
which
is
from
the
design
side.
If
we
can
make
the
non-mutable
feels
more
explicit,
because
that
was
a
bit
I
mean
you
mentioned
it
already
that
that's
not
so
easily
suitable
in
the
black
theme
in
a
dark
theme.
But
I
wonder
if
we
could
like
improve
this
somehow.
So
that's
one
part
and
the
other
one
is
the
the
selection
process
here,
where
you
have
to
say
field
where
it's
kind
of
clear.
E
F
J
Interesting,
I
like
it
actually,
so
you
know,
I
would
say
the
same
as
david
did
for
on
the
on
the
previous
flux.
One
you
know
like.
I
think
one
of
the
reason
was
that
okay,
I
wasn't
very
interested,
but
it
feels
like
the
original
idea
was
that
if
you
read
everything
from
left
to
right,
then
it
kind
of
sounds
like
the
sql
query.
J
You
know,
that's
why
there
is
like
the
from
and
the
where
and
the
select
and
so
on,
but
I
think
it's
okay
to
leave
that
that
terminology
there
and
we
just
said
I
mean
I
could
even
go
with
the
from
rename
to
database
or
bucket
or
what's
the
word
there.
You
know
and
there
will
be
the
filter
or
whatever
or
filter
by
tag
or
something
you
know
I
think
we
can.
We
can
leave
that
sqlish
terminology
for
the
rockery,
but
I
mean
that's
just
my
personal
opinion.
F
E
F
J
If
I
make
a
question
like,
I
missed
the
first
couple
minutes,
so
this
might
have
been
we
gone
through
this
one
like
for
example,
influx.
You
know
you
can
do
this
where
sections
with
and
then
or
but
like.
Obviously,
you
can't
do
some
of
those
booleanish
operations.
You
know
like
where
you
group
some
stuff
together
like
is
this
planned
to
be
worked
on
or
we
just
or
we
go
with
this
approach
here.
I
don't
know
if
it's
understandable
what.
F
C
J
This
trick,
where
it's
somehow
like,
I
think,
okay,
everything
that
is
one
line,
is
ended
together.
Even
if
you
or
that's
a
new
row-
and
you
know
you
are
ordering
together
the
rows
of
ants
or
vice
versa-
I
don't
know
which
one
if
I
for
I
forget,
but
maybe
make
sense
to
look
at
that
one.
I
I
feel
like
in
that
approach.
You
can
do
all
those
stuff,
whether
we
need
it
or
not.
J
It's
again,
maybe
a
question
I
mean
we
can
always
tell
the
user
that
if
something
is
not
possible,
that
please
use
the
raw
cure
editor
for
those
advanced
use
case.
So
I'm
not
saying
it
must
be
supported,
but
that's
something
that,
like
a
an
iit
person
like
you,
know
like
why
can't
I
express
those
those
those
relations
there.
J
Yeah
we're
good,
I
mean
I
I'm
not
saying
it's
a
real
use
case.
I'm
just
saying
that
right
now,
right
now,
it's
unclear
to
me
even
right
now
you
know
if
you,
if
you
create
like
four
of
these,
where
blocks
and
you
do
end
or
end.
Let's
say
I
don't
even
know
how
they
are
they're
composed
like
we
are
leaving
it
to
the
influx
database.
But
that
is
very
true
good
points.
L
I
I
think
she
had
an
idea,
or
we
talked
about
an
idea
that-
and
I
think
this
connects
to
the
to
the
trying
to
build
and
query
editor
for
non-tech
people,
or
maybe
people
that
don't
really
know
super
much
about
the
the
data
source
that
they
are
acquiring.
But
then,
then
we
had
an
idea
about
structuring
the
the
query
builder,
depending
on
what
kind
of
query
you're
trying
to
build.
L
So
basically,
if
you're
trying
to
build
a
time
series
query,
you
would
get
help
of
defining
like
you
need
to
have
a
time
field,
for
example,
and
at
least
one
value
field,
and
you
get
guided
in
like
building
a
query
that
will
result
result
in
that
kind
of
data
and
in
in
and
on
the
other
side.
If
you
just
want
to
query
like
table
data,
then
it
you
don't
have
any
of
those
like
criterias.
F
And
yeah,
so,
basically,
my
most
my
biggest
focus
has
been
sort
of
the
the
segment
component
that
I
used
is
used
today.
That
is
used
like
all
over
the
place
and
in
different
ways
and
usually
sort
of
being
used
in
a
sort
of
unintuitive
way.
I
mean
when
it
was
created.
It
was
basically
for
graphite
where
you
just
added
segments
like
in
a
chain
and
it,
and
in
that
case
it
sort
of
really
makes
sense.
F
B
The
other
thing
to
add
there
is
that
the
bi
team
does
have
sort
of
notions
towards
how
I
will
call
it
notions,
because
it's
not
really
a
plan
or
a
design
at
this
point.
But
an
idea
of
you
know
what
might
we
do
to
make
querying
easier
for
people
who
are
not
comfortable
querying,
but
it's
very
early
conversations
right
now,
but
I
think
that,
as
patrick
mentioned,
that
it's
a
little
outside
of
what
he's
doing
here,
but
it's
definitely
something
that
is
being
talked
about
quite
a
bit.
F
I
I
I
E
A
Google
sorry,
google
sheets
I'll,
put
a
screenshot
in
the
in
the
in
the
doc
but
like
how
I'm
sure
excel
does
simply,
but,
like
google
sheets
have
maybe
there's
numbers
actually,
I'm
thinking
of
the
mac.
The
mac
numbers
up,
how
it
kind
of
has
its
like
tries
to
have
a
prettier
ui
for
like
formulas
in
in
spreadsheets,
is,
I
guess,
kind
of
similar-ish
to
what
you're
talking
about
tokul.
E
F
I
E
F
K
F
F
C
H
F
F
So
with
azure
as
well
and
you're
sort
of
trying
to
figure
out
how
they
work
and
also
I
looked
a
bit-
I
haven't-
really
tried
anything
with
graphite
yeah
I
did
try.
Some
yes,
I
went
to
graphite
is
a
bit
special
because,
depending
on
how
you
build
the
query
it
through,
if
you
build
it
with
tags,
this
system
with
this
component
makes
sense.
But
if
you
just
do
it
the
old
way,
the
whole
segment
component
actually
works
to
get
better,
so
it
sort
of
depends
on
how
how
you
create
it.
I
I
Yeah,
this
is
actually
something
that
I
did
before
summer,
but
because
of
yeah
vacations
and
and-
and
I
think
there
was
some
you
know-
the
ux
session
was
cancelled
or
something
didn't
align.
So
I
didn't
get
a
chance
to
show
it
off
before
summer,
and
it's
let's
see
I
can
screen
it's
related
to
transformations.
So
in
eight
one
we
added
two
new,
really
kind
of
impactful
transformations.
I
I
So
think
of
you
want
to
have
the
threshold
line
as,
instead
of
being
that
being
hardcoded.
You
want
to
write
a
separate
query
that
can
query
for
that
threshold
line
or
another
example
would
be
that
you
want
to
to.
You,
have
a
table
in
your
sql
database
or
whatever.
That
has
the
sensor
that
has
the
unit.
Maybe
it
has
a
min
and
max
value,
and
you
want
to
use
that
min
and
max
value
when
in
your
gauge
or
in
your
visualization,
and
that's
what
what
these
two
new
transformations
does.
I
There's
one
that
called
config
from
query
where
you
have
a
separate
query
that
can
can
be
used
to
apply
configuration
to
another
query
and
as
an
example,
you
can
look
at
this
one
where
we
have
this
config
from
query
result
where
you
specify
a
name
of
the
query
that
should
be
used
for
for
configuration
and
I've
actually
named
name
this.
So
the
abc.
You
can
actually
change
that.
Those
query
default
query
names
to
something
more
meaningful
and
I've
changed.
I
This
query
name
to
config
and
I
can
then
select
it
here
and
specify
that
I
want
to
apply
apply
this
to
all
numerical
fields,
and
I
want
to
sort
of
map.
In
this
case
I
want
to
map
threshold
and
the
because
the
data
has
names.
That's
called
threshold,
one
all
of
this
kind
of
automatic,
so
it's
trying
to
kind
of
automatically
find
suitable
fields
and
map
those
two
to
display
settings
like
min
and
max
and
threshold
here.
I
But
the
thing
that
I
really
want
so
so
the
thing
that
I
I
wanted
to
do,
as
we
also
were
working
on
these
two
new
transformations,
was
also
to
improve
the
ease
of
use
a
little
bit
of
transformations
so,
and
I
wanted
also
to
make
it
possible
to
to
disable
a
transformation.
So
you
could
look
at
the
data
before
it
was
transformed,
so
I've
added.
So
if
I
look
at.
I
There
was
no
way
to
do
that,
and
so
the
the
solution
for
that
was
to
use
the
same
exact,
same
thing,
we'd
use
for
queries
to
use
the
I,
but
I
wanted
to
make
the
make
kind
of
be
before
inquiry
editors.
The
only
way
to
kind
of
show
that
a
query
was
disabled
was
we
changed
the
icon,
but
I
wanted
a
more
active
state
to
showcase
that
you've
actually
disabled
this
query
and
I'm
using
the
same
thing.
I
We
are
using
for
like
active,
active
tabs
here,
and
that
was
the
main
reason
for
that
was
that
I
also
explored
kind
of
making
information
about
transformations
more
accessible.
So
when
you
add
a
new
transformation,
you
get
these
helpful
descriptions
what
they
actually,
what
this
transformation
actually
do
and
I
wanted
to
make.
But
you
can't
see
that
descriptions
once
you
have
actually
added
the
transformation.
I
That
opens
a
markdown
that
can
show
you
either
the
description,
but
if,
if
there
is
also
a
health,
they
can
show
you
examples
for
how
to
actually
use
this
transformation
examples
of
outputs
and
inputs
and
what
this
transformation
does,
and
this
is
like
a
persisted
info
state
that
I
also
needed
an
active
state
for
in
this,
and
we
have
the
same
thing
for
debug,
which
is
also
an
active
kind
of
open
state
here,
so
that
this
was
something
I
was
adding
one.
So
all
these
all
transformations
now
can
be
disabled.
I
They
can
show,
if
you
don't,
have
an
not
all
have
these
examples
yet,
but
they
they
do,
show
the
description
and
a
link
to
the
transformation
documentation,
but
we
do
have
some,
but
for
some
of
them
I
wanted
to
have
some
more
guidance
in
that
or
a
link
to
the
docs.
So
that's
kind
of
the
the
gist
of
of
of
this
change
and
the
thing
as
the
thing
that
I'm
struggling
from
from
my
ux
perspective
was
like
yeah.
C
I
I
I
So
that's
why
I
kind
of
ended
up
with
this
kind
of
more
kind
of
open
state
that
is
with
a
help
box
that
is
not
really
tied
to
it's,
not
not
a
separate
box,
but
it's
more
tied
to
exactly
the
trend,
the
transformation
you're
in.
So
it's
not
it's
not
an
info
box
that
we
can
use
in
other
places.
I
think,
because
it's
kind
of
it
uses
the
the
header
as
a
way
to
collapse
and
open
it.
E
B
I
guess
what
I'm
trying
to
wrap
my
head
around
a
little
bit
right
now
is
sort
of
how
the
documentation
in
the
app
here
would
align
with
go
along
with
whatever
the
documentation
that
is
in
the
docs
you
know
so
like
are
we
going
to,
for
example,
make
sure
that
the
tech
writing
team
reviews
this
or
writes
it
or
you
know
like?
I
think
we
need
to
make
sure
that
that's
aligned
very
tightly
so
that
we
don't
have
inconsistencies
which
could
be
very
confusing.
A
I
M
One
thing
that
comes
to
my
mind
is:
we
should
be
consistent
in
how
we
are
displaying
the
information
for
some
of
them.
We
just
have
a
blurb
and
then
a
link
to
the
documentation
and
then
for
others.
We
have
examples,
and
you
know
more
content,
so
a
user
might
might
get
confused
by
that.
They
might
think
that
there's
some
missing
information
there
within
the
ui.
I
Yeah,
I
think
I
think,
obviously
it
would
be
better
be
optimal
if,
if
all
had
the
same
level
of
kind
of
in
detail
here,
but
in
the
absence
of
that,
I
think
it's
I
think,
having
having
more
detail
on
on
the
the
tricky
ones
is
also
fine,
and
it
is
it's
better
than
the
none
or
or
something
consistent.
Some
inconsistent
level
of
of
information
here
feels
like
better
than
none.
N
I
kind
of
understand
gina's
point
because
maybe
for
the
user,
since
this
is
something
new,
the
the
user
wouldn't
necessarily
know
if
that
is
less
complex
than
something
else
that
they
have
clicked
on,
and
maybe
the
user
may
wonder.
Okay,
why
did
I
find
more
information
in
one
and
not
in
the
other
one?
N
I
don't
know,
maybe
just
putting
ourselves
in
the
shoes
of
the
user
in
terms
of
trying
to
understand
it
better,
and
I
think
it's
great
to
have
this
kind
of
content
in
in
the
platform
just
to
to
give
them
a
little
bit
of
more
context
yeah.
So
I
would
also
vouch
for
for
having
the
same
level
of
information
if
it's
possible
for
for
all
of
the
transformations.
I
M
I
M
I
M
I
E
I
B
B
Strikethrough
would
do
I'm
just
thinking
about
it
from
like
an
accessibility
point
of
view
that
that
could
be.
I
don't
know
if
it
would
be
problematic.
We
might
want
to
look
at
that,
but
I
mean
just
generally
the
treatment
of
like
the
tab
treatment
under
the
icons.
Personally,
I
actually
like
that
quite
a
bit.
I
think
it
helps
a
lot
because
of
how
small
the
icons
are
to
distinguish
that,
but
that's.
C
I
O
I
just
have
one
more
question
for
patrick,
if
he's
still
around,
so
I
think
it
all
works
great.
So
I'm
curious
to
hear
about
the
next
steps
I
mean.
When
will
we
see
this
in
grafana
ui
and
I
mean
is
that
is
there?
Is
there
going
to
be
like
a
query?
Editor
part
of
grafana
ui?
Is
that
like
a
long-term
goal
here.
F
Can
you
hear
me
now
yeah
yeah
yeah,
so
the
idea
is
that
we
should
have
a
section
in
grifana
ui,
especially
for
query
builders,
and
it's
it's
basically
for
our
old
needs,
but
also
for
like
plug-in
builders
and
the
time
frame.
The
idea
is
we're.
Gonna
show
stuff
next
week
on,
the
community
called
hopefully
get
some
feedback
there,
and
my
goal
is
that
we
should
actually
try
implementing
them
in
a
data
source
after
8.2.
F
I
guess
in
late
september,
so
in
october,
have
it
implemented
in
one
data
source,
just
as
the
first
version
and
see
how
it
works
and
then
but
then
we
will
also
have
like
a
finished
guide
for
implement
using
it
and
so
forth.
So
yeah
I'm
going
on
parental
leave
in
november.
So
I
wouldn't
have
want
all
of
this
done
before
that.
So
that's
sort
of
the
time
frame,
I
guess.