►
From YouTube: UX Feedback Session 2021-08-18
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
but
I'll
go
through
like
some
of
the
improvements
and
see
what
your
thoughts
are.
So
the
first
one
is
basically
not
having
inline
labels
and
putting
them
on
top
of
the
inputs
instead.
So
if
you
just
look
here
and
compare
this
row,
for
instance,
I
find
this
easier
to
scan
and
read.
This
does
add,
and
I
think
the
apprehension
against
having
top
labels
in
the
query
builder
is
that
they
take
up
more
space,
but
in
some
cases
they
do.
A
So
that
is
that,
like
one
area
and
then
it's
also
sort
of
how
we
add
and
remove
the
segments
so
that
this
works
very
differently
in
different
data
sources,
where
you
sort
of
delete
things
and
add
things
and
so
forth
and
for
a
unified
way.
My
simple
suggestion
is
basically
that
when
you
add
things
in
a
row,
you
have
it
on
the
right
side
and
if
you
added,
like
a
new
row,
add
rows.
A
You
basically
just
have
it
at
the
bottom
and
just
try
to
keep
that
consistent
and
when
you
have
them
in
a
row,
you
basically
have
the
things
to
sort
of
remove
the
items
on
the
actual
item
rather
than
having
a
trashcan
anywhere,
and
then
you
would
sort
of
combine
them
into
adding
stuff
in
a
row
and
adding
rows.
And
then
you
can
remove
the
whole
row
or
just
items
inside
the
row
and
then
we
move
on
to
the
actual
segment
component.
A
So
in
the
current
implementation,
you
could
see
something
like
this,
that
you
have
like
your
key
equals
value
situation,
and
but
you
can't
really
see
which
parts
you
can
interact
with
or
not.
So
this
could
be
a
drop
down
three
drop
down,
so
you
can
just
look
out
that
you
can
change
or
it
could
be
two
drop
downs
and
an
input
or
it
could
be
a
drop
down
a
non-interactive
item
and
then
an
input.
A
So
my
suggestion
is
basically
that
we
actually
use
in
like
drop
downs
and
inputs,
rather
than
this
thing
that
looks
like
a
label
and
but
the
the
issue
here
is
then
like.
How
would
you
remove
them,
because
then
you
will
have
like
clusters
of
inputs
that
should
be
able
to
be
removable
and
edible,
so
this
is
just
like
having
some
sort
of
cross
somewhere
that
sort
of
removes
it.
A
This
is
my
initial
sort
of
idea
having
it
in
the
first
one,
but
then
it
looks
like
you
can
only
remove
the
first
one,
but
maybe
some
sort
of
interaction,
interactable
effect.
Basically,
if
you
hover
it
or
focus
the
eggs,
it
can
maybe
outline
the
whole
thing
that
will
be
removed
or
some
something
like
that,
so
how
they
sort
of
work
in
the
product.
A
It
will.
Basically,
you
have
this
sort
of
segment
group
and
you
would
add
a
segment
and
then,
depending
on
the
sort
of
segment
you
could
use,
it
could
be
like
this
version
or
this
version,
and
then
you
could
sort
of
continue
to
add
with
the
plus
and
continue
adding
them
and
also
having
either
and
or
an
end
or
depending
on
also
the
needs
for
you
that
data
source
and
that
sort
of
segment
that
is
needed
and
and
also
when
you
add
rows.
A
A
That
will
come
up
each
time.
You
add
a
new
dimension,
so
this
actually
does
not
take
up
a
lot
more
space
than
the
one
with
inline
labels,
and
I
do
think
it's
sort
of
less
intimidating,
looking
like
than
the
current
one.
So
this
is
sort
of
this
is
a
bit
more
like
a
ui
people
are
used
to
seeing,
I
would
say-
and
it
also
sort
of
reflects
a
bit
more,
what
the
actual
cloud
products
to
themselves.
A
So
this
is
what
this
could
look
like
in
influx
tv
with
this
system.
So
here
you
also
have
them
where
you
can
add
new
fields.
So
currently,
when
you
add
a
field,
you
get
sort
of
a
field
and
then
you
get
something
that
manipulates
it.
As
I
understand
it,
so,
in
the
current
implementation,
when
you
click
plus,
you
either
pick
a
new
row
or
another
item
to
the
row.
So
here's
quite
clearly
that
here
you
add
a
new
field,
and
here
you
can
add
new
sort
of
items
to
that
segment.
A
B
I
think
it's
a
great
exploration
that
you
have
done
and
yeah.
I
agree
that
having
labels
about
input
fields
is
pretty
much
like
the
standard
and
most
the
best
usability
or
accessibility
practice
that
you
could
have
two
things
that
I'm
wondering
so
for
the
segment
component
itself.
B
Why
not
follow
the
other
patterns
that
we
have
for
remove,
slash,
delete
and
have
that
inline
remove
on
the
right
hand,
side
of
things
it's
as
opposed
to
the
left.
So
when
you
say
in
this.
C
B
You
have
yeah
pretty
much
the
x
could
be
on
the
right.
I
think
it's
the
most
used
pattern
and
the
only
other
thing
that
I'm
thinking,
but
probably
that
just
will
raise
complexity
on
the
front-end
side
is
I'm
thinking
of
the
screen
that
the
user
has
right.
Some
might
have
very
large
screens
and
versus
narrow
ones
and
depending
on
how
they
use
their
computers.
B
B
It
could
be
like
a
personal
preference
of
to
save
some
of
the
space
and
fit
items
better,
but
I
think
overall
they
it's
a
good
exploration
and,
let's
see
who
else
wrote
after
me,
I
think
it
was
that
he
wanted
to
ask
a
question.
D
I
I
wanted
to
discuss
the
like
closing
or
deleting
a
portion
of
the
segment.
C
D
A
D
Yeah,
I
know
that
you're
already
creating
a
lot
more
space
by
making
them
drop
downs
instead
of
tags.
But
what,
if
you
added
more
and
added
a
container
around
them
and
then
put
the
x
floating
in
the
container
outside
of
the
drop
down?
I
think,
although
it
takes
up
more
space,
it
just
makes
it
more
explicit
that
when
you
click
the
x
you're
deleting
the
entire
segment,
not
just.
E
I
think
it's
an
interesting
commentary
the
one
like,
but
I
think
what
needs
exploration,
what
happens
if
you
have
like
this
extra
container?
What
happens
when
you
will
have
like
six
rows
with
this
additional
container,
because
that
can
be
a
massive
visual
clutter?
I
don't
know,
but
it's
just
a
thought
like
it's
interesting
to
try
this,
but
we
should
try
this
also
like
in
extreme
version
to
make
sure
this
is
not
too
much
visual
clutter.
If
we
do
that.
D
A
D
So
the
drop
downs
are
making
that
process
of
editing
it
more
explicit
yeah.
I
do
think
it
almost
gives
the
impression
having
the
delete
icon
inside
of
the
key
drop
down.
Isn't
it.
A
Yeah
yeah
definitely
so
I
mean
so
that
is
like
one
of
the
things
that
I
haven't
really
explored
enough
and
it's
really
early.
It's
just
like
the
idea
that
you
should
be
able
to
delete
the
whole
thing,
but
I'm
not
really
sure
how
to
indicate
it.
Yet.
A
D
D
F
Yeah,
so
hey
guys,
I
I
maintain
graphite
color
editor,
which
uses
segments
very
heavily.
So
that
could
be
that,
like
extreme
case,
because
in
graphite
you
basically
use
segments
to
build
a
metric
name,
and
it
can
be
like
a
very,
very
long
list
and
in
graphite.
You
also
have
this
pattern
with
key
value
for
tags
and
and
functions
and
they're
all
segments,
and
it's
like
super
confusing
how
to
delete
and
what
to
delete.
Sometimes
you
just
click
away
on
something.
F
Sometimes
you
put
empty
value,
I
I
guess
users
just
got
used
to
how
it
works
and
how
to
make
it
work.
But
it's
not
really
clear.
So
I
really
like
this,
how
it
makes
it
very
clear
what
can
be
changed?
How
and
and
what
can
be
removed,
and
my
only
concern
is
that,
with
like
with
graphite,
you
may
have
like
a
lot
of
drop
downs
like
this,
so
with
segments.
What
I
like
is
like
it's
super
readable,
so
you
can
have
like
multiple
queries.
F
Each
query
can
have
a
lot
of
a
lot
of
segments
and
you
can
just
read
them
like
like,
like
it
was
a
text
and
only
when
you
have
to
edit
it
you.
You
actually
display
this
drop
down
with
all
these
drop
downs.
It
depends
on
the
on
the
design-
I
guess,
but
it
may
be
more
cluttered
and
and
more
confu,
basically
less
readable,
like
the
the
query
itself
may
become
less
readable,
because
I
think
this
is
also
important
aspect.
F
It's
not
only
for
editing
and
changing,
but
also
to
read
basically
to
see
what
is
inside
the
query
and
and
and
and
readability
is
also
important
here
but
yeah.
I
really
like
how
how
it
becomes
more
explicit,
with
especially
with
this
x,
to
delete
like
the
key
key
value
pair
or
entire
row.
A
Cool
yeah,
I
think
one
of
the
things
there
is
just
that
I
mean
graphite
is
the
extreme
case,
and
it's
also
like
every
other
data
source.
Query
builder
is
sort
of
based
on
the
graphite
one,
which
is
quite
good
for
graphite,
but
much
less.
So
for
basically
any
other
query
builder,
I
would
say
so:
that's
definitely
a
challenge
and
josh
had
a.
G
Yup,
so
just
a
couple
of
notes
on
labels,
one
is
that
I
really
like
the
labels
on
top
of
the
drop
downs
rather
than
on
the
side.
I
think
that
helps
considerably,
but
the
other
thing
when
I
was
thinking
about
labels
is
that
ryan
demonstrated
something
to
us
yesterday.
That
was
using
the
term
dimensions
for
what
I
think
was
something
different.
So
we'll
just
want
to
make
sure
that,
in
terms
of
that
phrasing,
we're
careful
about
what
things
are
sharing
names.
A
A
So
that's
why
the
labels
can
sometimes
be
confusing
if
you
go
from
one
data
source
to
another.
One.
B
Okay,
any
other
feedback
that
you'd
like
to
give
patrick
that
we
have
one
more
minute.
Two
more
minutes.
D
Yes,
I
have
a
couple
things
and
I
know
that
I
think
lukasz
and
oh
no,
they
deleted
their
their
signups.
So
I
guess
I
have
the
rest
of
the
time.
First,
I'm
going
to
show
the
table
component.
I've
been
doing
some
explorations
with
the
table
component
to
address
two
main
issues
issue.
D
One
is
that,
with
the
themes
update,
my
opinion
is
that
the
zebra
striping
makes
the
table
sort
of
like
not
grounded,
especially
when
it's
a
complex
table
with
a
lot
of
elements
in
it
like
buttons
and
text
links
and
icons,
and
things
like
that
and
then.
Secondly,
I
just
found
that
we
have
inconsistency
across
the
whole
app
in
terms
of
what
our
tables
look
like.
D
I'm
working
on
designs
to
translate
a
mixer,
the
irm
app
that
we
just
acquired
translating
their
ui
to
ours,
and
I
couldn't
recommend
which
table
we
used
because
we
have
so
many.
So
that's
sort
of
like
what
got
me
started
on
this,
but
I'll
share.
Just
my
explorations
and
members
of
the
ux
team
have
already
added
a
lot
of
comments.
So
thank
you
for
that.
D
I
have
not
had
time
to
go
through
them
yet
because
I
had
a
lot
of
meetings
yesterday,
but
essentially
I
I
started
looking
at
where
we
have
tables
in
our
app.
We
have
some
zebra
striping
in
some
places
and
as
you
can
see,
one
of
every
other
row
is
actually
the
same
as
the
background
color
and
then
in
other
places.
We
have
sort
of
like
a
horizontal
line
that
divides
them,
and
so
I
thought
of
these
two
methods
of
separating
rows
as
sort
of
like
the
main
ways
to
separate
rows.
D
I
haven't
explored
any
versions
other
than
that,
but
I
was
thinking
how
to
use
these
two
things
but
ground
the
table
more
against
the
background,
and
so
I
created
a
couple
options
with
some
zebra
striping
to
both
ground
the
table
against
the
background
and
also
sort
of
like
more
differentiate
what
the
header
is,
and
so
here's
a
simple
table
using
zebra
striping
and
then
a
complex
table
there
like
tags
and
inputs
and
links
and
buttons
and
expandable
rows.
D
D
So
this
was
one
option.
I
created
another
option
where
it
has
sort
of
like
a
container
behind
it,
so
that
you
can
see
that
this
component
exists
and
it's
it's
all
one
thing,
and
then
here
was
another
option
where
it
has
just
a
simple
border
around
it
to
again
ground
the
table.
Against
the
background.
D
I
Hey
teddy,
I
have
one
question:
what's
the
maximum
number
of
rows
that
we
that
we
have
in
tables
so
far
in
the
product?
That's.
D
A
good
question
and
I
wasn't
able
to
figure
it
out
through
just
like
some
discovery
and
playing
around
in
the
tool.
I
found
that
we
have
different
max
rows
in
each
table.
It's
not
built
into
like
the
max
rows
and
pagination
isn't
built
into
the
table
component
in
our
components,
library,
if
at
least
I
think
so
yeah
so
whoever's
implementing
it
implements
different
rules
along
with
it.
So
we
have
that
inconsistency
throughout
the
app.
C
I
think
sorry,
if
I
just
very
quickly
like
I
think,
though,
I'm
looking
at
this
for
like
to
using
azure,
monitor
for
our
resource
picker,
and
that
is
theoretically
an
infinite
amount
of
rows
in
that,
because
we're
just
visualizing
someone
else's
resource
in
there,
which
I
think
is
a
very
common
thing
for
us
to
do.
In
grafana.
B
To
answer
alias
questions,
there
are
situations
where
we
should
avoid
using
vagination,
because
you
have
to
see
the
whole
thing
at
once.
For
example
in
alerting
you
don't
want
to
miss
an
alert
that
is
on
the
other
page
and
it's
vibrant
and
we
are
halfway
cases
where
pagination
actually
makes
sense
so
for
feedback
for
teddy
personal
preference.
B
I,
like
both
the
option
with
just
the
border
on
the
table
because
it
doesn't
add
up
space
to
the
existing
table.
If
we
are
gonna,
do
a
padding
around
it.
Probably
we'll
break
a
few
areas
here
and
there
they
also
like
even
more
the
action
where
we
ditch
the
zebra
and
we
go
forward
having
lines
because
that
could
allow
us
to
have
highlighting
on
hoover.
B
So
when
you
look
at
a
large
a
big
table,
it
will
be
maybe
even
easier
to
highlight
only
the
row
that
you
are
currently
looking
at
and
in
both
in
all
cases.
I
really
like
seeing
that
table
column
the
row
header
being
more
obvious,
like
exactly
what
you're
showing
right
now.
B
D
That's
a
good
question.
My
intention
would
be
to
sort
of
like
agree
upon
standards
and
design
for
the
table
and
to
use
that
going
forward.
Potentially
at
some
point.
If
we're
updating
like
a
page
or
a
table
on
an
existing
part
of
the
app,
then
we
might
update
the
component.
D
Yeah,
I
think,
if
there's
a
really
solid
reason
for
using
two
designs
and
that
we
have
clear
standardized
rules
about
when
to
use
table
a
and
when
to
use
table
b,
my
opinions
that
that
is
fine,
but
if
it's
sort
of
just
like
personal
preference
or
we
say
oh
well,
this
table
works
better
on
this
part
and
then
this
table
works
better.
On
the
other
part,
that's
just
going
to
encourage
like
a
lot
more
inconsistency,
yep,
okay,.
G
Thank
you
and
then
I
had
another
question,
which
is
that,
in
terms
of
you
know,
I
know
that
this
is
an
exploration
and
we're
kind
of
narrowing
it
down.
But
once
we
get
down
to
some
kind
of
like
front
runners,
is
it
possible
to
run
some
a
b
tests
on
these
and
get
some
community
feedback?
Is
that
something
we
do
we'll
do
can
do.
E
I
think,
with
a
b
testing,
it
can
be
a
bit
tricky
because
that
is
really
hard
way
to
evaluate
this
based
on
a
b
testing,
but
that's
actually
something.
I
also
commented
on
like
for
me.
It's
also
personally,
the
alternating
row.
Colors
are
easier
on
eyes,
like
it's
easier
to
look
at
it
than
having
tons
of
lines,
especially
with
possibly
endless
tables.
But
that
being
said,
I'm
pretty
sure,
because
it's
like
a
ui
thing,
I'm
pretty
sure,
there's
a
bunch
of
like
eye
tracking
research
around
this
or
research.
E
That
tells
what
is
the
best
practice
there,
and
I
think
we
should
simply
follow
best
practice
and
what
was
researched
there
when
we
make
this
decision
and
also
I
fully
agree
on
making
this
like
a
standard
design
for
tables
like
we
shouldn't
be
switching
between
two
types
of
tables.
We
should
design
the
one
that
is,
that
is
the
best
based
on
like
research,
that
is
there
and
best
practice
and
just
stick
with
it.
E
Instead
of
having
like
two
types
of
tables
to
to
choose
from
because
we
will
never
get
the
consistency,
we
already
have
a
ton
of
different
tables
in
the
product,
so
yeah.
So
my
like
recommendation
and
piece
of
feedback
would
be
to
maybe
now
check
what's
there
when
it
comes
to
best
practices
and
research
on
this
and
then
take
it
from
there.
D
D
It's
like
I'm
sure
that
there's
there's
more
research
out
there
to
be
done
as
well,
but
that
was
sort
of
like
what
I
read
from
the
article.
B
E
C
This
work
looks
great,
though,
as
a
developer.
I
am
really
excited
to
see
some
I'm
really
excited
about
the
possibility
of
having
standardized
styles
and
components
for
this,
because
we
implemented
a
whole
bunch
of
custom
stuff
for
like
within
again
within
azure,
monitor
that
I
would
love
to
delete
and
not
have
that
code
hanging
around.
B
Oh,
I
wonder
if
we
could
take
like
an
approach
like
try
to
figure
out
in
on
the
choreographer
features
in
how
many
places
we
use
zebra
style
tables
and
where
we
don't,
we
don't
use
it
for
data
tables
behind
a
panel,
for
example.
That
is
we
use.
We
have
only
lines
we
use
ziploc
tables,
on
the
other
hand,
in
alert
and
I'm
sure
there
are
examples,
but
maybe
we
can
count
how
what
we
have
and
just
choose
the
option.
D
That
might
actually
be
something
that
I
would
request
that
our
team
helps
with
I
I
fold
a
couple
like
just
literally
two
examples
here,
and
I
wanted
to
do
more
of
that,
just
like
sort
of
do
an
audit
of
our
tables,
but
I
realize
I
just
don't
have
a
lot
of
features
in
my
grafana
accounts
like
I
know.
D
A
lot
of
enterprise
features
have
tables,
and
I
just
don't
have
access
to
those
things,
and
I
I
I
guess
I'm
just
wondering
if
maybe
that's
something
we
could
collaborate
on
as
a
team
is
pulling
in
examples
of
tables
just
here,
so
that
we
can
look
at
a
lot
of
them.
E
You
can
tell
you
can
also
like
what
usually
works
with
stuff,
like
that
just
publishing
ux
channel,
that
whoever
is
there
just
to
like,
because
those
don't
have
to
be
designers
right,
probably
engineers
have
even
better
overview
what
they're
putting
tables
so
just
ask
everyone
to
contribute
to
this
exploration.
That
sounds
good.