►
From YouTube: Grafana UX Feedback Session 2021-08-11
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).
B
Awesome
yeah,
let
me
share
my
screen,
so
what
I
wanted
to
bring
up.
We
had
a
customer
file,
an
issue
where,
in
certain
situations,
the
span
duration
is
hidden,
it's
cut
off
from
the
window
and
there's
also
some
extra
metadata
with
that.
I
don't
think
it's
a
huge
issue,
but
as
recent
as
recently
escalated
by
the
customer,
and
so
I
wanted
to
get
all
of
your
your
opinions
about
if
there's
something
you
know
good
alternative
of
where
we
can
place
this
information,
also
what
I'm
talking
about.
B
So
this
is
here
in
tempo,
where
we're
visualizing
traces,
and
so
each
of
these
little
sections
is
a
span,
there's
some
metadata
associated
with
it,
and
that
will
either
be
placed
on
the
right
or
left
of
the
span
in
this
right
pane.
So
it
will
show
the
duration
as
well.
As
you
know,
the
service
that
this
is
coming
from,
there's
also
a
couple
other.
You
know
places
that
this
is
being
shown
like
on
the
top
bar.
It
shows
the
total
duration
for
that
span.
B
If
you
click
into
a
span,
it'll
also
show
the
duration
here.
This
right,
pane
can
be,
you
know,
extended,
and
then
some
of
that
information
is
also
here
in
the
left
pane
like
the
service
that
the
span
is
coming
from,
and
so
the
issue
in
particular
is
that
the
customer,
with
their
data
a
lot
of
times
the
span
duration,
is
cut
off.
This
is
kind
of
a
small
screenshot.
B
It's
hard
to
see,
but
you'll
see
that
you
only
see
kind
of
the
the
seconds
of
this
span
just
based
off
of
kind
of
like
the
relative
lengths
of
the
the
different
spans.
So
in
the
example
that
I
have
here,
the
root
span
is
very
long
compared
to
the
other
spans.
So
there's
plenty
of
space
to
show
the
duration,
but
in
some
situations
or
like,
if
you
really
shrink
the
screen
down,
then
you
can
get
them
to
cut
off
or
also
when
you
hover.
B
C
I
have
one
question,
which
is:
how
how
is
it
determined
if
the
label
is
on
the
left
or
the
right
of
the
bar?
Is
that
just.
B
Yeah,
it's
programmatically.
I
haven't
looked
at
the
code
super
recently
to
remember
exactly
how
it's
working,
but
I
think
more
or
less
it
looks
where
there's
available
space
so,
for
example,
here
these
spans
start
right
at
the
beginning.
You
think
of
this
is
like
zero
seconds
and
so
that
places
them
on
the
right.
Something
that's
interesting
is
if
you
actually
look
in
the
inspector
this
root
span,
it
is
also
rendering
this
extra
data
to
the
right,
but
it's
completely
cut
off.
B
So
if
I
expand
this
out,
I
don't
know
if
you're
able
to
see,
but
that
actual
that's
absolutely
positioned
there
as
well
the
782
milliseconds.
You
might
be
able
to
see
kind
of
on
the
middle
right
of
the
screen
that
it's
hovering
showing
where
that
is.
Although
the
user
can't
see
it.
C
I
have
one
more,
I
think
I
asked
you
this
before
or
over
slack,
but
it's
been
a
couple
weeks.
So
if
you
can
refresh
my
memory,
what
are
these
typical
lengths
of
time
like
to
have
like
hundreds
of
milliseconds
to
a
hundredth
precision?
Is
that
typical,
or
can
it
range
like
completely
widely
like?
Could
we
have
like
millions
of
milliseconds
or
is?
Are
we
generally
looking
at
like
a
what
it
looks
like
a
three
to
five
digit
measurement.
B
Yeah,
that's
that's
pretty
standard,
and
so,
depending
on
what
the
length
is
it'll
change
the
units,
so
it
could
be
in
milliseconds.
I
think
in
this
example
I
have
some
longer
ones,
and
so
it
automatically
shows
them
as
seconds,
for
example,
and
I
think
the
code
will
do
that.
You
know
up
to
hours
or
days.
You
know
it'll
use
the
units
so
that
only
a
couple
digits
are
shown.
D
B
I
mean
the
actual
duration
right
is
pretty
small.
This
is
probably
the
longest
that
it
would
be
where
it's
like
five
numbers,
and
then
you
know
two
characters.
B
The
other
kind
of
variable
part
of
this,
though,
is
that
we
also
show
the
kind
of
like
the
service
that
the
span
is
coming
from,
and
that
could
vary
a
lot.
E
B
I
think
it's
added
as
an
area
label,
so
if
you
I'm
not
totally
sure
so,
maybe
if
you
I
don't
know,
if
you
can
tab
over
the
spans,
you
can
also
click
to
expand,
and
so,
if
that
is
keyboard
accessible,
then
the
information
is
also
shown
there.
I'm
not
totally
sure.
E
B
Yeah,
I
think
it's,
my
guess
is
because
it's
duplicated
so
you'll
see
here,
like
this
has
front
end
driver
driver
service
by
nearest
that
information
is
right
here
in
the
left
pane
as
well,
so
it
might
help
kind
of
contextualize
it
when
you're
looking
at
a
a
specific
span,
but
I'm
not
sure
the
reasoning
why
it's
only
shown
in
hover.
My
guess
is
to
to
keep
it
less
cluttered.
D
B
Yeah,
in
my
experience,
the
first
band
pretty
much
always
takes
up
the
entire
duration.
You
know
the
entire
width,
but
you
know
the
data
can
vary
widely,
depending
on
the
service
and
kind
of
like
the
shape
of
the
customer's
data.
For
my
limited
experience
yeah,
it
is
pretty
much
always
the
full
width
and
then
for
the
most
part,
there
are
there's
enough
room
to
render
out
the
duration.
I
think
it's
kind
of
an
edge
case.
In
my
opinion,
what
this
customer
is
experiencing
and
so
yeah.
D
D
B
The
fact
that
the
child
spans
also
take
up
almost
the
entire
duration-
we
don't
have
a
great
screenshot
here
under.
I
can't
remember
if
they
added
another
screenshot
in
the
issue.
No,
they
didn't.
B
My
guess
is
that
takes
up
the
whole
width
and
so
the
only
available
space
they
have
is
a
little
bit
right
there.
So
that's
kind
of
where
the
you
know
the
app
decides
to
display
that.
D
Got
it
got
it
and
just
one
final
question:
I'm
sorry
for
the
for
the
first
span.
Is
it
critical
that
they
have
the
one
that
takes
up
the
full
width?
Is
it
critical
that
they
have
the
kind
of
like
same
type
of
metadata
available
on
that
span,
or
is
that
spin
kind
of
like
for
the
use
case
kind
of
outside
of
that
yeah.
B
D
D
B
Yeah,
so
that's
why
my
first
proposed
solution
is
you
know
we
don't
do
anything.
We
say
this
information
is
already
available.
It's
pretty
quick
to
be
able
to
to
see
it.
I've
talked
a
little
bit
with
my
team
and
then
I
went
back
and
forth
chatting
with
a
couple
of
you
in
the
ux
channel.
You
know
there
are
a
lot
of
kind
of
pros
and
cons
to
each
of
the
proposed
solutions,
so
just
kind
of
give
an
overview
of
what
those
might
be.
B
So
first
do
nothing.
They
can
see
that
information
doesn't
seem,
in
my
opinion,
like
something
that
there's
a
great
solution
to,
and
some
of
the
other
ideas
were
put
the
duration
inside
of
the
span
instead
of
the
left
or
the
right.
One
issue
with
this
is
it
would
overlap
potentially
with
the
log
markers
which
I
don't
think
there
are
any
on
this
example.
Maybe
here,
okay,
yeah
so
in
here,
you'll
see
some
of
these
small
lines
that
respond
corresponds
to
logs
or
kind
of
other
events
that
happened
during
that
time.
B
B
Second,
proposed
solution
is
out
of
beneath
like
kibana.
Does
this
wastes
a
lot
of
vertical
space
and
then
a
lot
of
these
traces?
We
have
tons
and
tons
of
spans.
So
there's
a
lot
of
scrolling
as
is-
and
you
know,
in
the
majority
of
cases,
we
do
have
a
lot
of
good,
horizontal
space
that
we
can
use.
This
is
what
kibana
looks
like
and
how
they
have
the
information
below
each
span.
B
So
that's
one
alternative
and
for
context.
This
visualizer
is
forked
basically
from
jaeger,
and
I
think
zipkin
does
something
pretty
similar.
So
this
seems
like
the
most
common
layout
what
we
currently
have,
so
I
would
be
adding
it
beneath
it.
B
One
idea
would
be
to
add
the
duration
to
the
left
pane
so
right
now
we
already
have
kind
of
like
the
service
name
and
some
data
about
each
span
here
in
the
left
main,
we
could
add
the
duration
as
well
to
there
kind
of
moves
the
data
outside
of
this
context,
because
on
the
right
pane,
you
kind
of
have
this
sense
of
how
long
the
spans
are
relative
to
each
other,
and
they
have
that
information
there
and
it's
also
kind
of
nice
to
see
it
in
relation
to
kind
of
like
the
total
duration
of
the
the
trace.
B
B
So
that's
one
alternative,
maybe
remove
all
this
data
from
here
and
add
the
duration
to
the
left
pane.
What
else
one
idea
is
to
make
the
duration
hover
and
that
right
now,
basically,
this
left
pane.
It
sits
over
the
the
right
pane
so
see.
If
I
can
size
it
down
small
enough
so
you'll
see
here
when
I
hover
it
over
it.
The
the
service
name
is
hidden
underneath
the
left
pane.
One
alternative
is,
you
know
like
bump
up
the
z
index
of
this,
so
that
it
will
appear
over
anything
to
the
left.
B
Throw
that
on
my
screen,
set
up
right
now
won't
be
able
to
quite
show
it,
but
you
can
imagine
that
on
a
smaller
screen
or
depending
on
how
long
the
date
is
on
either
side
that
could
potentially
overlap.
So
I
think,
if
I
really
shrunk,
my
screen
down
see
that
if
we
hovered
or
made
the
the
information
on
the
right
side
appear
above
the
left
it
would,
you
know,
cover
over
that
information,
not
a
perfect
solution
there
either,
but
one
alternative.
B
I
think
those
were
kind
of
the
main
ones
that
that
we
had
discussed
and
that
my
my
team
had
brought
up.
Do
you
have
any
ideas,
alternatives
or
any
that
stand
out
as
being
worth
investigating
more.
C
C
Flush
left
with
the
right
hand
pane?
So
that
makes
sense
so
like
so,
if
you,
if
you
don't
mind
going
back
so
like
there's
your
little
divider
line
between
the
two
panes
and
all
of
your
gra,
your
graphics
starts
flush
left.
So
like
can
we
just
like
give
it
14,
pixels
of
padding
or
whatever
you
might
need?
You
might
need
a
little
more
than
that,
just
so
that
those
numbers
aren't
cut
off
and
then
have
the
tool
tip
hover
over.
C
So
it's
sort
of
like
a
combination
of
the
like
of
the
changing
the
overlap,
so
the
right
hand
pane
comes
to
the
front,
but
then
also
just
buying
yourself
some
space
and
starting
a
little
further
to
the
right
instead
of
flush
left
with
that
pain,
divider.
C
D
I
have
a
question
about
it,
though,
because
would
that
be
dependent,
like
the
amount
of
space
you're
padding
with
you
would
need,
but
that'd
be
dependent
on
kind
of
like
the
size
of
the
service
name,
and
it
sounds
like
or
the
length
of
the
service
name
and
like
we're,
not
sure,
because
it's
kind
of
like
user
defined
like
how
long
those
service
names
would
be.
So
you
could
probably
have
something
pretty
wacky,
I'm
assuming
not
lagging.
C
But
you
know
yeah
well.
What
I
was
thinking
actually
was
that
the
service
name,
since
it
only
appears
on
hover
that
we
still
would
just
hover
it,
but
it
would
come
to
the
front
of
the
pane
of
the
service
and
operation
pane,
but
that
you're
just
buying
yourself
space
with
that
padding
for
the
time
measurement.
So
the
time
measurement
would
always
show,
and
would
you
know
we
could
reserve
what
is
like.
You
know
a
reasonable
amount
of
space,
because
we
do
have
a
fair
amount
of
horizontal
space,
but
then
on
hover.
C
It
could
overlap
on
the
left
hand
pane
if
it
needs
to
it's,
not
elegant.
It's
not
great,
so
I'm
very
open
to
other
ideas,
because
it's
like
a
combo
approach.
A
I
have
a
question
because
that
issue
is
basically
around
the
longest
time
span
or
the
basically
the
time
span
hidden
for
the
really
long
lines.
Let's
say:
isn't
it
possible
to
just
basically
for
the
for
the
first
line
to
overlay
from
the
left
side
overlay,
the
total
span
duration.
Basically,
on
top
of
the
line.
B
A
Yeah,
but
if
you
would
like
place
that
we
don't
have
annotations
turned
on
on
that
zoom
call,
so
I
think
I
cannot
all
I
can
annotate.
A
If
that
would
be
just
something
like
placed
here
like
a
pill
with
the
total
number,
we
still
have
some
some
space
here
available
and
that
would
basically
like
solve
the
issue.
B
Yeah,
the
logs
could
appear
at
any
point
along
the
the
span
yeah,
I
think
that's
an
alternative
solution
as
well
as
placing
it
inside
the
span.
B
Yeah,
that's
the
main
issue
because
the
root
span
you
can
see
the
length
based
on
the
total
length
here.
The
more
pressing
issue
is:
if
one
of
the
child
spans
is,
you
know
you
think
of
it.
If
it's
pretty
much
the
same
width
as
the
root
spin,
then
there's
going
to
be
an
issue
because
there's
not
going
to
be
space
on
either
side.
Unless
we
reserve
space,
like
amy,
mentioned
on
one
of
the
sides
to
always
show
the
the
duration.
A
Yeah
that's
the
case
that
is
shown
within
the
issue
that
is
not
shown
here.
What
you
display
that,
basically
on
the
issue,
the
two
spawns
below
are
basically
as
long
as
the
the
main
one,
so
yeah,
but
then
again
why?
A
If
we
know
that
we
cannot
display
that
information
and
that
can
be
of
various
lengths,
I
guess
like
14
pixels
doesn't
buy
us
more,
so
it
should
be
then
around
at
least
like
well
much
more
because
it
can
be
in
thousands
of
milliseconds,
for
example,
or
something
like
that,
I
guess
so.
If
we
know
that
we
cannot
display
that
because
it's
basically
overflows
the
this
part,
why
just
not
move
it
to
the
right
and
place
it
on
top
of
that
line?
There
are
no
informations
on
top
of
that
line.
Basically,.
A
Yeah
because
it
seems
like
all
of
those
additional
improvements
are
super
interesting
and
super
relevant,
but
the
escalated
issue
is
basically
around
displaying
this
specific
information,
this
specific
context,
so
so
how
to
solve
that
issue
the
shortest
way.
Basically,
that's
the
question
and
then
to
have
a
discussion
about
overall
improvements
to
that
if
they
are
possible.
C
So
one
of
the
things
that
I
think
we
have
to
be
really
careful
about
if
we
overlay
the
label
is
the
contrast.
So,
like
the
what
fifth
one
down
the
light
blue
one
is
gonna
fail
all
of
our
accessibility
checkers
if
we
overlay
the
label,
so
I
don't
know
if
we
would
do
it
in
sort
of
like
an
enclosed
filled
box
or
something.
C
E
A
Yeah,
we
can
add
an
underlay
or
like
a
pill
like
make
a
fill
out
out
of
that.
Basically,
why
not?
It
doesn't
have
to
be
just
like
a
the
text
move
to
the
right.
It
can
be
some
additional
styling
beneath,
because
that
text
will
not
also
fit
the
height
of
that
bar,
and
it
will
look
ugly,
so
additional
visual
things
really
need
to
be
there.
I
guess
to
make
it
more
pretty
and
readable.
E
B
A
I
maybe
also
the
alternative
to
the
pill
and
something
that
doesn't
require
much
of
the
work
is,
for
the
time
spans
that
do
not
fit
the
time
span
label
within
the
viewport,
maybe
yeah.
We
could
just
like
place
the
time
spans
here.
A
B
C
I
mean,
I
think,
that
we
are
saved
a
little
bit
by
the
fact
that
you
can
resize
the
pains
so
like,
even
if
they
have
it
and
it's
cut
off,
they
could
always
kind
of
like
drag
it
out
a
little
bit
to
see.
You
know
what
I
mean
like
to
just.
C
If,
if
the
left
pane
is
getting
cut
off,
they
could
drag
it
out
because
at
a
certain
point
you
know
definitely
what
they're
saying
now
is
problematic,
but
if
they
just
have
this
on
like
a
teeny,
tiny
screen
and
are
trying
to
do
kind
of
crazy
things,
it's
like
looking
at
excel
right,
like
you,
can
only
make
your
columns
so
small
and
you
can
only
handle
it
so
many
different
ways
before
it's
just
kind
of
on
you
as
a
user,
to
make
it
visible
to
yourself.
C
So
I
I
think
that
that's
why
I'm
leaning
towards
you
know
a
combo
of
what
I
said
and
what
lukas
said,
which
is
this
left-hand
label
and
just
using
up
some
of
that
real
estate
over
there
are
do
we
does
the
left-hand
pane
get
like
really
deeply
nested,
or
is
this
more
typical
of
like
six
or
so
levels,
steep.
B
B
Okay,
so
it
sounds
like
two
of
the
solutions
that
we're
leaning
towards
investigating
would
be
showing
it
inside
of
this,
the
the
span
with
some
extra
styling,
so
that
it
has
enough
contrast-
and
you
know
it
doesn't
look
awkward-
just
kind
of
like
being
placed
right
over
it
since
the
the
span
isn't
tall
enough
to
show
all
that
information.
B
Another
would
be
adding
some
padding
so
that
the
duration
is
always
shown
inside
the
left,
pane,
which
would
effectively
kind
of
like
shrink
everything
down,
since
all
the
spans
are
spaced
relative
to
each
other,
and
you
know
just
having
some
extra
space
here
and
I
think
one
alternative
you
mentioned
as
well.
I'd
be
interested
to
hear
your
thoughts
you
know.
Do
we
need
this
information
here
associated
with
each
span?
Would
it
work
just
as
well
to
include
the
duration
here
in
the
left
pane?
B
The
service
information
is
also
duplicated.
I
think
that
could
also
be
a
a
relatively
simple
solution
to
implement
and
because
you
can
resize
the
left
pane
pretty
easily.
I
think,
if
we're
not
losing
any
information
by
removing
these
and
putting
them
here
from
an
implementation
standpoint,
I
like
that
one,
the
most.
D
I
actually
I
agree.
I
had
been
thinking
about
that
as
well
like
we're,
showing
the
information
twice
right
so
like
is
it
necessary?
The
one
thing
I
would
say
is
maybe
on
hover,
you
see,
there's
a
bit
more
contrast
on
the
on
the
right
side,
because
it's
kind
of
like
the
white,
and
I
wonder
if
on
hover
you
could
have
that
same
kind
of
contrast,
say,
for
example,
with
the
service
name,
because
it's
in
gray,
but
maybe
on
hover.
You
could
do
that
yeah.
D
C
B
Yeah,
I
think
it'd
make
that
a
lot
easier
to
see
the
information,
and
I
don't
think
it
would
be
too
bad
because
we
already
have
it
going
one
way
right
like
if
I
hover
over
the
left,
the
right
gets
highlighted
and
I
think
doing
it.
The
other
way
would
not
be
too
bad.
A
Yeah,
I
I
I
somehow
like.
I
feel
that
this
is.
A
Like
yeah,
that
information
is
duplicated,
but
if
you
can
imagine
that
someone
is
working
on
solving
some
kind
of
a
problem
and
they
need
to
go
through
many
lines
of
those
and
they
want
to
identify
the
specific
service
or
the
specific,
like
a
error
or
or
code
that
happened
and
if
they're
far
away
to
the
right
with
exploring
those
spawns,
then
just
like
a
hovering
there
and
having
that
information
within
the
reach
of
the
focused
eye.
A
Let's
say
this
is
this:
may
might
make
a
huge
difference,
especially
on
a
bigger
screen,
so
it
might
be
like
a
thousands
of
pixels
away
if
you
want
to
check
which
of
those
spawns
is
raised
to
which
of
the
elements
so
like
here.
It's
just
like
a.
I
know
we
can
guide
that
by
hover,
but
basically
it's
a
huge
jump
for
the
eyes
still
to
make.
So
so
I
think,
there's
a
reason
for
that
information
to
be
attached
on
hover.
There.
D
Okay,
no,
I
think
that
makes
sense.
I
think
one
thing
we
haven't
explored
is
the
idea
of
like
a
tooltip
or
some
kind
of
like,
like
a
tooltip
on
hover.
I
don't
know
if
that's
something
you
thought
about
at
all,
connor.
B
Yeah
so
in
this
screenshot
it's
hard
kind
of
hard
to
see,
but
I'm
hovering
over
this
span
and
there's
a
tooltip
above
it.
I
think
that's
an
alternative
as
well.
It
does
look
kind
of
weird
when
you
have
the
the
tooltip
and
the
info
to
the
right
yeah.
That
is
another
alternative
as
well.
B
What
if
we,
you
know,
duplicated
all
of
the
information
and
we
included
the
duration
on
the
left
panel
as
well,
so
you
still
have
a
contextualized,
but
in
situations
where
it's
cut
off,
you
can
pretty
quickly
look
over
to
the
left
and
I
think
of
those
situations
where
that
kind
of
edge
case
is
popping
up.
Those
are
already
spans
that
are
pretty
close
to
the
left
pane
and
that
might
be
an
easy
way
to
see
the
duration
as
well.
B
F
A
Yes,
like,
I
just
wanted
to
confirm
that
we
are
talking
about
like
placing
those
labels
either
to
the
right
side
or
to
just
basically
next
to
the
other
labels.
Already
there's
like
a
two
options
to
either
have
it
like
here
or
have
it
like
here
duplicated.
We
are
already
duplicating
the
information,
so
sounds
like
a
reasonable
thing
to
do.
E
B
Yeah,
my
thought
is
to
have
it
here
on
the
left
be
easier
to
implement
and
then,
if
it's
on
the
right
and
you're
kind
of
absolutely
positioning
it,
I
guess
you
could.
You
know
just
like
have
a
spacing
element
in
between
my
guess.
Is
that
if
you
shrink
it
down,
then
you're
hovering?
You
know
the
duration
hover
over.
You
know
overlay
over
that
or
the
other
way
around.
So
I
think
just
having
it
on
the
the
right
of
the
service
name
would
be
the
simplest.
A
So
yeah,
so
I
guess
what
you're
saying
also
is
that
yeah?
Maybe
I
was
thinking
too
much
too
much
flag
of
flexbox
and
then
it
would
be
easier
to
just
like
push
that
element
to
the
right
side.
But
I
guess
it's
not
done
with
flexbox.
I
guess.
B
Yeah,
I
think,
let's
see
I
guess
these
are
links.
I
don't
know
why.
They're
can
you
click
on?
I
don't
know
why
those
are
links
but
yeah.
It's
just
text
inside
the
same
element.
I
guess
you
could
make
it
flexbox
and
then
space
them
out
that
way.
So
I
guess
implementation,
wise
yeah,
I'm
probably
not
a
problem.
I
don't
have
any
opinion
either
way.
A
Yeah,
but
it
seems
like
having
them
here
is
also
a
good
option
for
start,
and
it
covers
the
escalation
issue
as
well
by
just
enabling
to
see
the
time
span
for
each
of
the
spawns
like
lines,
basically
so
yeah.
A
B
Yeah,
I
agree,
I
think,
go
ahead.
You
go
ahead.
I
was
just
gonna
say
yeah,
I
think.
Obviously,
from
our
perspective,
you
know
it
being
simpler.
To
implement
is
great.
I
think
it
will
reliably
show
the
information
I'm
leaning
towards
you
know
implementing
this,
and
then
we
can
revisit
this
in
the
future
kind
of
like
adding
additional
context
to
this
as
well.
So
we
mean
for
a
while.
B
We
were
maintaining
a
fork
of
jaeger
more
or
less
so
that
we
could
have
this
trace
visualizer,
but
we're
kind
of
drifting
more
and
more
away
from
that.
So
we
can
keep
considering.
You
know
like
ways
that
we
can
innovate
or
just
like
change
what
that
was,
since
we
are
no
longer
tied
to
the
original
source
code
of
you
know
like
how
yeager
did
things.
D
And
connor
just
one
more
thing,
so
I
do
think
if
you
could
hover
over
on
the
right
side,
just
one
of
the
yeah.
A
D
Of
the
stands
yeah
yeah,
so
I
think
something
like
it
and
lucas.
I'm
not
sure
if
this
this
kind
of
this
doesn't
drive
with
what
you
were
saying,
but
I'm
wondering
if
you
want
to
have
it
look
the
same
way
in
both
places.
Just
for
consistency,
so
say,
for
example,
you
would
even
kind
of
you
would
you
would
really
just
I
mean
here
you
have
kind
of
like
the
front
end.
D
I
mean
I
don't
know
if
you
could
have
it
look
exactly
the
same
way.
You
probably
wouldn't
need
the
front
end
kind
of
like
the
name
of
the
service.
I
guess
appended
on
the
left
side,
but
if
you
would
have
the
numbers
and
then
the
name
of
the
service,
just
for
consistency's
sake,
if
something
like
that
works.
A
Yeah,
although
that
is
hard,
because
the
like
the
alignment
shifts
from
the
right
side
to
the
left
side
and
also
that
the
order
changes,
I
think,
like
there's,
also
a
reason
why
the
front-end
selector
is
there
like
with
the
double
semicolon,
because
maybe
that
allows
you
to
copy
that
and
then
to
use
it
elsewhere.
To
also
look
for
that
specific
lock
element.
So
so
yeah,
the
consistency
is
great,
but
then
you
would
have
to
rewrite
the
the
selector
as
well.
If
you
want
to
copy
that
in
a
different
place
to
look
for
things.
A
Yeah,
you
can
probably
right
now
you
can
just
like
select
the
whole
string
starting
from
front
end
and
ending
with
the
customer
and
paste
it
somewhere
else
when
you
are
looking
through
the
logs
or
doing
whatever
else,
and
if
we
just
present
it
with
this
like
a
nicer
front-end
label,
then
you
miss
the
double
double
colon
selector,
which
basically
means
it
is
harder
to
copy
and
paste
the
text.
A
Think
but
I
don't
know
if
that's
really
the
case,
I'm
just
like
looking
for
for
reasons
that
it
was
implemented
this
way,
and
maybe
that
was
a
part
of
some
other
issue
or
or
future
requests
so
yeah.
But
I
don't
know,
I'm
not
sure
about
that.
Definitely.
B
As
far
as
I
know,
I
don't
think
there's
any
specific
functionality
tied
to
kind
of
like
that.
Formatting
one
idea
that
comes
to
mind
is
having
the
duration
on
the
right
might
make
it
a
little
bit
more
easily
scannable.
You
know
like
keeping
the
service
and
operation
together.
I
think
makes
sense
because
those
are
you
know
like
similar
pieces
of
information
and
then
I
feel
like
it
might
look
a
little
bit
weird
putting
the
duration
in
between
them.
That's
my
initial
thought.
A
And
if
we
change
order,
then
when
we,
if
we
have
the
front
end,
http
get
customer
first
and
the
milliseconds
after
that,
basically
on
a
hover,
the
milliseconds
label
will
have
to
jump
to
the
right
or
so
that
will
make
that
information
shift
from
one
place
to
another.
A
B
Yeah,
I
think
that
that
made
sense
you
know
if
we
want
them
to
be
in
the
same
order:
we'd
have
to
flip
one
or
the
other
kind
of
discuss.
So
we
probably
don't
want
to
change
this
order
and
yeah.
I
think
it
would
not
work
too
well
if
we
flipped
this
order
either.
B
Do
we
have
any
other
feedback
or
ideas
regarding
this?
Just
to
summarize,
you
know
the
idea
of
showing
the
duration
simply
here
appended
to
to
this
information,
so
it's
visible
in
both
places.
You
can
still
see
it
contextually,
but
in
those
kind
of
edge
cases,
it's
very
easy
to
see
the
info
as
well.
A
B
A
Cool
because,
like
it's
like
a
you
connor
and
us
the
ux
team
conor,
are
there
any
things
we
might
improve
with
that
session
for
the
future,
to
make
it
more
valuable
for,
for
you.
B
A
Okay,
cool,
thank
you
so,
and
thank
you
very
much
for
presenting
that
and
having
that
during
the
feedback
session,
and
I
guess
we'll
see,
see,
see
you
all
during
the
next
week's
feedback
session.