►
From YouTube: UX Showcase: Sticky Issue Titles
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
A
So
we'll
start
with
a
quick
story:
we
have
Parker
one
of
our
personas,
of
course,
who
is
a
busy
p.m.
using
it
lab
and
they've
recently
been
mentioned
in
an
issue
by
someone
who's
on
their
team?
The
issue
is
a
couple
of
years
old,
so
there's
a
lot
of
discussion.
Lots
of
comments
and
Parker
is
seeing
it
for
the
very
first
time.
A
So
this
means
that
when
Parker
clicks,
the
link
there
dropped
deep
into
that
lengthy
discussion
within
the
issue
page
and
they
review
the
person's
comment.
But
it
doesn't
really
provide
a
lot
of
context
as
to
what
the
issue
itself
is
about.
So
in
order
to
know
how
to
respond,
Parker
has
to
scroll
to
the
very
top
of
the
page,
to
review
those
initial
details
and
then
scroll
back
to
the
original
developers
comment
in
order
to
reply
which
can
create
a
jarring
kind
of
slow
experience.
This
is
probably
a
scenario.
A
A
So
I
considered
the
need
for
seeing
header
related
information
from
any
point
on
the
page
to
be
a
problem
of
both
slow
for
the
user
and
context.
So
I
wanted
to
start
by
considering
the
use
cases.
I
wanted
to
validate
my
assumptions
about
the
problem
and
explore
ways
to
reduce
some
of
that
friction
in
the
flow,
as
well
as
provide
context
for
the
users,
particularly
when
they
were
reviewing
an
issue
for
the
first
time
from
top
to
bottom.
What
did
they
need
to
know
right
off
the
bat?
A
What
would
they
do
when
first
trying
to
understand
what
an
issue
was
about?
How
did
that
change
the
experience
for
them
for
users
when
they
are
dropped,
kind
of
mid
conversation
into
an
issue
by
being
mentioned
in
it,
to
do
or
being
sent
a
link
to
a
specific
conversation
point,
and
then,
when
revisiting
an
issue?
So
does
the
value
of
what
they
see
in
the
header
change
after
they
read
over
an
issue,
but
perhaps
have
forgotten
some
of
the
details.
A
So
what
initially
led
us
to
work
on
this
was
reviewing
opportunities
to
improve
the
loved
ability
of
issue
tracking
for
a
plan
and
UX.
Okay
are
there
was
a
lot
of
discussion
initially
about
this,
especially
surrounding
in
the
MVC,
and
what
we
wanted
to
offer.
But
the
question
that
I
wanted
to
explore
was
what
information
is
going
to
be
most
valuable
from
the
top
of
the
page
when
reviewing
discussions,
and
why
so.
We
assume
the
title
of
course,
but
we
also
felt
that
maybe
status
could
be
important.
A
We
wondered
about
tabs
adding
those
in
and
if
they
could
be
useful
for
quick
access
to
the
top
of
the
discussion
thread.
Consistency
with
merge
requests,
since
they
have
the
tab
section
at
the
top
and
then,
of
course,
discoverability
of
design
management
as
an
opportunity
as
well.
So
I
decided
to
do
some
quick
internal
testing
to
get
better
understanding
of
what
would
be
valuable.
A
I
gave
them
the
scenario
of
imagine
that
you
have
just
been
sent
this
issue
for
the
first
time,
just
kind
of
talk
through
the
process
of
digesting
this
issue
and
sharing
what
what
you
think
it's
about
and
how
you
would
start
to
learn
that
information
as
you
go
through
it
then
I
had
them.
Stop
Midway
kind
of
deep
into
that
discussion.
Point
and
tell
me
what
they
recall
about
the
original
idea
for
the
issue,
as
well
as
what
they'd
find
useful
at
this
point
to
gain
better
understanding
of
what
that
was
about.
A
This
was
an
attempt
to
understand
if
there
needs
to
changed
based
on
that
content,
so
I
would
have
them
write
on
a
scale
of
one
to
five,
the
breadcrumbs,
the
status,
the
author
information,
the
timestamp,
those
types
of
features,
so
we
got
some
really
interesting
insights.
This
was
really
kind
of
exciting.
For
me,
the
title
was
considered
to
be
the
most
important
that
wasn't
a
big
surprise
to
us,
but
it
was
great
to
get
that
validation
followed
by
status
and
description.
A
Most
said
that
tabs
would
be
very
important
if
they
used
design
management
but
admitted
that
they
didn't
currently.
So
this
could
be
a
good
discoverability
opportunity
here
and
I
think
that
that's
something
that
we've
talked
about
internally
on
our
stage
and
I
think
we've
also
touched
on
it
with
the
other
stage.
That
was
that
particular
feature
from
top
to
bottom
users
tended
to
review
the
title,
and
then
they
would
skip
the
conversation
or
skip
straight
to
the
conversation
and
start
skimming
that
they
would
skip
the
description
and
the
related
content
altogether.
A
As
a
matter
of
fact,
the
only
times
that
people
felt
that
description
was
valuable
was
when
they
just
could
not
figure
out
the
information
they
needed
to
respond
to
a
comment,
and
the
title
didn't
offer
enough
clarity
in
itself
and
then
related.
They
would
really
only
pay
attention
to
you
if
they
were
actively
working
on
that
particular
issue,
so
those
two
particular
pieces
of
they
tended
to
just
bypass
all
together
breadcrumbs
date
created
an
author
were
important,
but
only
in
the
case
where
additional
context
was
needed
to
understand
more
about
that
particular
issue.
A
So,
for
example,
if
they
weren't
sure
what
project
they
were
in
or
what
group
they
were
in,
then
they
would
go
to
the
breadcrumbs
to
seek
that
information,
but
it
was
not
important
at
all
times.
Users
didn't
find
edit
valuable
in
nearly
all
cases
unless
they
had
created
the
issue
themselves,
so
people
felt
very
uncomfortable
changing
an
issue
that
they
didn't.
They
didn't
actually
create
that
they
weren't
the
official
owners
of
at
least
in
their
minds.
A
So
I
thought
that
was
kind
of
interesting
and
was
curious
as
to
why
that
was
but
didn't
we
didn't
want
to
spend
a
lot
of
time
on
that
for
this
particular
feature,
so
I
didn't
dive
too
deeply.
Unfortunately,
in
order
to
restore
context,
women
tagged
in
a
specific
point.
In
the
conversation,
most
users
would
just
refresh
the
page
after
scrolling
and
to
see
the
title,
so
they
would
be
dropped
back
down
to
that
content.
That's
something
I
know
I've
done
as
well.
A
You
get
tagged
in
a
comment
you
scroll
to
the
top
to
get
some
context
and
then,
rather
than
having
to
just
scroll
up
and
down
and
figure
out
where
you
were
coming
from,
you
would
just
refresh
the
page,
because
the
URL
has
that
context
already
provided
the
most
people
would
use
that
approach
to
take
them
back
to
a
previous
contact
comment.
So
lots
of
kind
of
jumping
around
unfortunately,
and
then
status
was
most
important
to
avoid
commenting
on
a
closed
issue,
but
that
was
the
main
reason
that
people
said
they
found.
That
particular
feature
valuable.
A
So
to
summarize,
the
value
for
the
customer
and
I
would
say
us
internally
as
well.
Users
were
having
trouble
understanding
context
within
issues
because
they
couldn't
see
the
title
information.
This
created
friction
within
the
general
flow
of
consuming
that
asynchronous
content
within
within
issues
slowed
down
the
experience,
an
added
frustration
for
the
user
because
of
the
extensive
scrolling
and
kind
of
jumping
around
on
the
page.
You
can
see
some
of
the
comments
here
from
users
expressing
some
of
that
frustration.
A
So
a
job
here
was
for
the
user.
That
reviews
and
participates
in
asynchronous
discussions.
They
need
the
ability
to
understand
at
a
high
level,
the
overall
context
from
any
place
within
the
conversation
so
that
they
know
how
to
respond
to
the
discussion
as
quickly
and
accurately
as
possible.
And
again
we
wanted
to
reduce
any
friction
for
them
in
that
process
and
for
the
business
goal.
A
So
for
NBC,
which
you
can
see
today,
of
course
on
get
lab
comm.
We
decided
on
a
fixed
header
that
appears
once
the
user
has
swirled
past
the
title.
We
reduced
the
font
size
of
the
title
to
minimize
the
real-estate
cost
involved.
This
was
definitely
a
concern
for
us
and
for
some
users
expressed
by
some
users
as
part
of
our
research
included
status,
so
users
would
always
know
if
an
issue
is
open
or
closed
before
commenting
on
it.
A
So
that
was
another
reason
that
we
decided
to
go
back
to
this
kind
of
sticky
element
approach,
I'm,
happy
to
say
that
we
have
received
nothing
but
positive
feedback
so
far
on
this-
and
here
are
a
handful
of
the
comments
that
we've
received-
I'm
not
going
to
go
through
them
all
for
times
sake,
but
it's
been
very
positive
and
very
good
response.
So
far,
so
for
future.
Of
course,
our
primary
focus
with
this
is
to
keep
it
simple,
always
always
be
mindful
of
the
real-estate
cost.
A
A
So
if
you
are
dropped
in
to
a
conversation
you
have
to
scroll
to
the
top
or
you
can
click
the
title
as
well
actually,
and
that
will
take
you
to
the
top
to
get
a
little
more
context,
having
a
button
or
an
option
to
be
able
to
quickly.
Take
you
right
back
to
where
you
were
so
you
don't
have
to
do
that
hard
page
refresh.
Take
you
back
to
that
point
in
the
conversation
is
something
else
that
we
are
looking
to
explore.
A
We
might
potentially
include
tabs
for
discussion
and
design
management
in
the
future,
both
for
consistency
with
merge
requests
using
that
tab
approach,
but
also,
to
perhaps
add
some
more
discoverability
to
design
management.
But
again
we
want
to
be
mindful
of
the
real
estate
costs,
so
that's
something
that
we're
still
kind
of
exploring,
possibly
changing
the
states
of
the
header
a
little
bit
as
you
scroll
deeper
into
the
issue.
So
it
gets
a
little
shorter
or
a
little
taller,
depending
on
where
you
are
and
reveals
more
or
less
information.
Again
up
for
discussion.
A
We
haven't
finalized
anything
there,
yet
we're
just
kind
of
talking
through
options
and
then,
of
course,
going
back
to
consistency
with
epics
and
M
ours.
How
can
we
carry
over
existing
patterns
into
other
areas
of
the
product
to
ensure
that
everything
feels
and
looks
the
same?
It
is
familiar
to
users
as
they
navigate
through
and
that's
it
for
sticky
titles
would
love
any
feedback.
Any
questions
that
anyone
might
have.