►
From YouTube: Create:Editor Product/UX Weekly - 2020-12-09
Description
Weekly Editor group sync between Product, Design, and UX Research
A
All
right,
hello,
everyone-
this
is
the
december
9th
editor
product
design,
ux
sync
meeting.
Looking
at
the
agenda
ahead
of
time,
there
was
lots
to
talk
about
from
the
ongoing
research
and
and
design
solution
validation.
So
I
defer
all
my
topics
to
michael
and
catherine,
we'll
just
turn
it
over
to
you.
Take
it
away.
B
Okay,
cool.
When
I
first
saw
I
differ
my
topics.
I
thought
that
meant
like
you,
can
push
our
stuff
away.
B
A
Tomorrow
is
our
our
editor
monthly
with
the
engineering
group,
and
I
I
anticipate
running
through
some
some
product
updates
in
that
one
and
going
category
by
category,
but
there's
nothing
new
to
this
group
and
I'm
really
interested
to
hear
how
solution
validation
is
going.
So,
let's
use
that
time
for
resistance.
B
Great
yeah,
so
solution
validation
is
going
well
this
week.
It
was
amazing
that,
like
at
the
beginning
of
the
week
I
had
like
one
scheduled
and
then
by
the
time
I
wrote
my
like
by
the
end
of
monday,
I
had
like
four
or
five
scheduled,
so
thank
you
very
much,
catherine
for
your
recruitment
on
that
it
is
much
more
effective
than
even
me
doing.
Internal
recruitment
for
stuff
so
like
mine,
would
like
stretch
out
like
three
weeks
or
something
so
this
was
really
good
to
see.
So
I
was
like
pleasantly
surprised.
B
So
the
areas
that
we've
been
looking
at
for
this
solution,
validation
is
first
and
foremost
the
consolidation
is
our
project.
Groups
are
more
high
level,
and
the
other
thing
that
we
wanted
to
look
is
also
like
the
pattern
of
switching
between
like
projects,
whether
we
want
to
keep
people
in
context
or
whether
we
should
take
them
to
the
project
overview
and
first
thing
is
the
drop
down.
Menu
seems
like
having
all
the
options
in
there.
People
are
really
happy
to
see.
B
Of
course,
people
want
to
customize
it
and
there's
other
things
that
are
interesting,
where
people
see
milestones
in
there,
but
they're
like
what
about
iterations,
should
they
be
in
there
too,
and
like
oh,
okay,
that's
a
that's
an
interesting
one,
but,
like
gut
feel,
it
feels
like
it's
safe
to
consolidate
those
things
about
navigation
of
like
projects
or
take
them
to
their
projects.
Overview
yeah.
B
By
my
surprise,
people
like
the
idea
of
transitioning
back
to
the
home
page
and
then
moving
out
one
of
the
quotes
that
people
one
person
said
was
like
I
like
to
see
where
home
is
before.
I
move
out
something:
okay,
that
kind
of
makes
sense
and
switching
between
projects
using
the
breadcrumb
areas
seemed
more
obvious,
even
for
participants
who
are
kind
of
new
to
gitlab,
because
they
they
saw
it
as
being
in
context
of
the
switching.
So
so
that's
so
that's
an
interesting
tidbit
there.
B
C
B
I'll
post
that
more
in
the
video
to
explain
the
rationale
there.
So
some
of
the
points
I
have
in
here
is,
like
other
applications,
kind
of
do
it
just
by
the
luck
of
the
way
it's
structured.
It
looks
like
it's
maintaining
context,
but
it's
not
but-
and
I
think,
there's
something
interesting
with
the
way
our
ia
is
structured.
I
don't
believe
switching.
It
makes
sense
because
it
introduces
another
area
to
switch
projects
and
whether
we
do
that
or
not
is
more
a
product
decision.
B
One
thing:
that's
like
super
obvious:
if
you
want
an
issue
to
move
ahead
on,
is
this
idea
of
simplifying
the
user
menu
so
within
the
user
menu
on
the
top
right,
where
there
is
the
drop
down
to
go
to
your
profile,
edit,
your
profile
preferences
and
all
that
it
was
brought
up
to
me
a
few
weeks
ago
around
like
adding
a
toggle
for
dark
mode
in
there
I
was
like
oh
yeah,
sounds
easy,
but
then
I
was
rearranging
some
of
the
user
menus
and
then
I
discovered
a
issue
ticket
from
maybe
one
or
two
years
ago,
and
the
person
who
created
that
ticket
came
to
the
same
kind
of
conclusion.
B
So
it
felt
like
two
people
k.
Two
people
in
two
different
times
within
git
lab,
came
out
with
the
same
solution
and
testing
it
with
users
with
four
people.
So
far,
people
found
it
like
straightforward
and
some
people
even
noticed
that
it
was
simpler
than
the
current
one,
because
the
current
one
makes
them
choose
too
much.
So
it
is
something
that
I'm
happy
to
just
say
like
go
ahead
with
that
and
it
could
open
another
slot
for
like
toggling
or
whatever.
So
I
think,
that's
a
it
feels
straightforward
and
what
else
toggle
menu?
B
One
of
the
one
of
the
few
issues
are,
I
see
our
team
tackling
is
like
toggling,
the
left
side,
sidebar,
visibility
of
the
menu
item,
and
I
created
this
issue
last
week.
I'm
not
sure
if
people
saw,
but
I
think
the
root
cause
of
a
lot
of
internal
discussions
and
potential
confusions
with
users
is
that
when
you
toggle
off
a
feature
or
when
you
toggle
toggle,
you
turn
off
the
functionality
and
in
the
menu
item
and
sometimes
there's
things
that
are
interrelated,
that
you
don't
want
to
turn
off
the
functionality
of.
B
But
you
may
want
to
hide
the
visibility
of,
and
I
feel
like
if
we
just
separated
the
two
or
added
another
kind
of
flag
to
say
this
is
a
menu
toggle,
and
this
is
like
a
feature
toggle.
So
this
way
we
can
turn
off
the
functionality.
If
you
don't
want
your
your
company
to
use
like
kubernetes
but
yeah,
but
but
you
just
want
to
hide
like
merge,
requests
from
a
project
that
has
issues
or
something
so
you
can
have
that
granular
control.
B
I
didn't
have
time
over
the
past
few
days
to
like
come
up
with
a
visual
proposal
of
what
that
should
look
like,
but
that's
what
I
want
to
do
over
the
next
few
days
to
help
get
that
moving,
because
I
see
us
tackling
more
and
more
of
those
issues
and
we
get
into
like
long
discussions
within
the
comments
where
I
see
like
people
like.
Oh,
don't
turn
it
off
completely,
because
sometimes
people
might
need
logs
in
operations
and
like
okay.
That
makes
a
lot
of
sense.
B
We
just
wanted
to
hide
all
the
other
things,
and
so
I
think
somewhere
along
the
way
we
got
bigger
than
a
one-to-one
relationship
between
features
and
menu
visibility,
and
I
think
that's
what
this
is
trying
to
address.
B
And
that
brings
me
forth
to
the
next
thing
that
I'll
be
looking
for
to
like
set
up
solution.
Validation
is
settings
and
the
three
themes
around
settings
is
the
inline
search
behavior
the
pattern
around
adding
an
item
to
settings
and
overall
layout
and
navigation
feedback.
So
this
is
the
idea
of
how
might
we
navigate
back
to
where
we
came
from
if
we
like
talk,
triggered
settings
from
within,
say
the
merge
request,
page
or
somewhere
in
the
repository
like?
B
C
B
B
A
I
just
love
to
know,
I
think
the
user
menu
sounds
like
a
really
good
win.
I've
come
across
that
issue
as
well.
It's
a
clear
one.
Let's
try
and
get
that
in
13
8..
A
It
also
seems
like
the
menu
consolidation
is
getting
close.
If
we
can
come
to
a
clear
enough
conclusion,
I
think
we
could
start
to
iterate
towards
that
in
138
and,
if
not,
then
maybe
something
in
the
breadcrumbs,
but
I'm
looking
forward
to
your
video
I'm
open
to
the
idea
that
it's
not
a
pattern
we
want
to
introduce.
A
I
think
the
goal
is
for
consistency
in
the
pattern
that
exists
with
other
left
nav
items
in
that
you
can
turn
off
things
like
the
wiki
on
a
project
right
and
you
shouldn't
have
to
see
it
in
the
left.
Nav.
If
you
turn
it
off,
not
every
feature
can
be
turned
off
and
maybe
not
every
feature
should
be
able
to
be
turned
off,
but
those
that
do
should
also
have
their
left
nav
items
hidden.
But
this
opens
up
a
problem
which
is
like
now
you
turned
off
the
wiki.
A
You
don't
know
about
the
wiki,
you
don't
know
about
the
great
features
we're
adding
to
the
wiki.
You
don't
have
your
your.
Your
contributors
can't
decide
for
themselves
whether
or
not
they
want
to
use
a
wiki.
So
it's
it's
kind
of
like
a
a
really
drastic
measure
to
turn
that
off
on
a
on
a
project.
In
some
cases
this
is
right,
like
certain
types
of
projects
may
just
not
be
applicable
like
there
might
be
features
that
are
not
applicable
to
a
native
ios
app
or
something
like
that.
A
I
would
like
to
spend
a
little
more
time,
thinking
about
this
and
maybe
schedule
some
time
with
the
growth
team
to
discuss
like
how
can
we
build
this
into
sort
of
the
new
project,
setup
or
group
admin
to
promote
feature
awareness,
because
I
think
if
we
do
it
right,
like
the
way
you're
describing
which
is
like
separating
the
idea
of
visibility
from
actually
turning
off
functionality,
we
could
still
go
down
the
path
of
having
much
more
curated
persona
based
navigation
or
like
giving
people
the
ability
to
filter
out
only
what
they
need
to
see
while
still
making
features
available
to
other
users
on
the
project.
A
A
B
B
My
rough
ideas
around
this
because
I
see
it
from
feature
and
like
separating
those
two
is
that
you
could
promote
a
feature
within
the
feature
area
like
hey
this.
This
is
something
new
discover
it
and
then
everything
else
above
is
like
all
your
active
ones.
So
it's
like
there's
always
like
this
lurking
area
that
potentially
could
introduce
you
to
new
features
and
stuff
like
that.
Yeah,
yes,.
A
You
also
bring
up
a
good
point
about
how
they're
interconnected
and
I'm
hopeful
that
catherine
might
touch
on
this
in
her
research
with
the
left,
nav
baselining.
A
But
I
think
the
I
think,
the
more
immediate
goal
that
we
can
have
as
a
group
is
to
try
and
clean
up
that
information
architecture,
not
necessarily
with
the
sole
purpose
of
going
one
to
one
with
features
that
can
be
turned
off
or
turned
on.
But
a
good.
A
I've
seen
illustrated
is
like
if
you
want
to
turn
off
issues.
Maybe
you
use
jira
at
your
work
and
you
you
don't
want
to
use
gitlab
issues
and
you're
never
going
to
want
to
use
git,
lab
issues,
issues
and
labels
and
some
of
the
plan,
functionality
that
are
related.
They
show
up
in
multiple
places
and
that's
where
it
can
get
kind
of
complicated,
so
yeah
anyway.
A
I
just
just
to
just
to
highlight
that
other
topic
that
you
brought
up,
I
think
that's
that's
part
of
it
and
again
we
can
kind
of
take
a
baby
step
towards
towards
making
it
more
clear
how
the
features
on
that
left.
Nab
are
organized
and
then,
hopefully,
when
it
does
come
time
to
like
deactivate
something
that
has
its
its
impact
is
felt
across
multiple
items.
Maybe
it'll
be
easier
to
to
map
that.
A
C
Okay,
are
there
any
other
thoughts
on
likewise
points?
Okay,
so
then
I'll
I'll
go
into
mine,
so
mine
is
a
update,
so
currently
have
two
benchmarking
studies
in
progress.
So
the
first
one
is
a
moderated
like
usability
testing
study
around
wayfinding
and
promoting
interaction
with
the
top
navbar,
but
sometimes
not,
but
that's
the
goal
of
that
study.
And
so
far
two
interviews
have
been
completed
and
I
believe
it
should
wrap
up
either
monday
or
tuesday
had
one
reschedule.
C
So
that
should
be
good
in
terms
of
kind
of
having
the
current
experience
benchmarked
and
then
being
able
to
discuss
with
michael
what
he
learned
from
his
testing
of
the
prototype
and
see.
Were
there
any
things
that
stood
out
in
both
of
them
anything
that
was
clearly
a
better
concept
in
the
prototype
versus
existing
things
like
that,
so
I'm
excited
to
be
able
to
sync
on
that
and
then
the
other
one
is
a
tree
test
of
the
group
level
left
sidebar,
which
is
basically
a
findability
test.
C
C
C
For
example,
we
have
parts
of
the
sidebar
that
are
more
purpose
oriented.
I
don't
know
how
else
to
say
it
like
security
and
compliance,
ci
cd
operations,
and
then
we
have
other
parts
that
are
more
feature
based
like
issues
and
merge
requests.
So
we're
going
to
need
to
kind
of
find
the
balance
between
the
two
because
with
the
purpose-based
ones,
there's
kind
of
better
categorization,
but
there's
more
layers
of
navigating
to
go
through
and
then
the
other
way
around
it's
more
clear
and
direct,
but
it
makes
the
sidebar
longer
and
there's
more
and
more
items.
C
So
we
kind
of
have
to
find
a
balance
there
or
see
if
we
need
to
think
bigger
entirely
about
the
whole
thing.
But
that's
what
that
issue
is
about,
and
then
my
to-do
here
so
still
have
some
progress
to
make
on
the
setting
study,
which
should
align
well
with
the
next
direction
that
michael's
going.
So
that's
good
and
then
there
will
also
be
a
project
level
left
sidebar
benchmark
so
that
both
of
them
have
been
tested.
A
From
from
my
standpoint,
I
think
this
list
you
have
is
is
exactly
what
I
would
prioritize.
I
think
we
are
already
working
on,
but
understand
that
it's
a
it
can
get
complicated
the
idea
of
enabling
disabling
settings.
We
hear
this
a
lot
but,
as
we
just
touched
on,
it
can
get
complicated
depending
on
the
issue.
I
think
the
in
regards
to
the
okr.
We
have
two
issues
related
to
that
in
13-7.
A
I
don't
know
if
by
the
17th
or
not,
but
that
will
be
close,
they'll
likely
be
done
by
the
end
of
the
quarter.
We
might
be
able
to
pick
up
a
couple
more
of
those.
My
impression
was
that
there
are
some
others
that
are
more
straightforward
and
we
can
just
follow
a
repeatable
pattern.
We
might
be
able
to
pick
up
another
one
in
138
or
something
plus
the
user
menu.
The
improvements
to
the
username
that
we
touched
on
seem
pretty
clear
cut.
A
I
think
we
can
get
those
in
13.8
and
we're
doing
technical
research
on
the
searchable
settings,
and
I
think
that
has
resulted
in
a
really
a
really
tangible
mvc
that
we
can
shift
in
13
8
that
improves
it
incrementally,
but
puts
us
on
the
path
towards
a
more
holistic
solution
for
globally
searching
settings
and
just
to
surface
a
little
bit
of
the
summary
of
that
discussion.
Enrique
was
doing
the
research
there
and
keeping
in
mind
you
know
capacity
and
availability.
A
And
what
we,
what
it's
looking
like
we'll
do,
is
any
of
the
settings
pages
that
have
multiple
sections,
the
expanding
and
collapsing
pattern
or
multiple
areas
of
functionality
within
a
settings.
Page
we'll
add
a
search
bar
and
there's
a
list
in
the
in
the
technical
issue
that
will
be
turned
into
implementation
issues
in
the
next
day
or
so,
and
that
will
be
just
basically
a
search
from
within
that
page.
A
So
it
won't
globally
serve
settings
but,
for
example,
in
the
general
project
settings
view
where
you
have
a
whole
hodgepodge
of
different
settings,
you'd
be
able
to
search
for
like
merge,
request,
approvals
and
it'll
filter
down
the
page
to
show
you
just
that
setting
highlight
it
for
you
and
you
can
take
action
on
it.
I
think
that
my
you
know.
B
A
Everybody
wants
the
global
search
experience,
but
we
need
to.
I
think
we
need
to
wait
on
some
of
the
research
and
solution
validation.
That's
going
on
that
michael
mentioned,
and
once
we
have
a
more
clear
and
clean
ui
pattern
for
settings,
then
we
can
work
backwards
towards
a
or
work
forwards
towards
a
a
way
to
index
those
settings
and
provide
a
back-end
search,
a
back-end
powered
search
that
that's
more
global.
C
A
I
think
we'll
have
plenty
for
thirteen,
eight
and
and
probably
thirteen
nine.
They
might
not
be
the
most
impactful
changes
that
we're
researching,
but
they
are
tangible
and
and
will
be
improvements
for
sure
yeah.
So
I
think,
as
far
as
the
okra
is
concerned,
I
think
we're
on
track
to
at
least
get
80,
if
not
all
the
way
with
the
the
number
of
implementation
issues,
but
I
don't
want
to.
C
B
Yeah
on
the
topic
of
the
search
one,
I
haven't
gone
through
all
the
comments
that
has
transpired
over
the
last
day
or
so
on
that.
But
one
of
the
things
that
I
was
talking
to
enrique
is
that
we
are
doing
solution
validations
on
kind
of
like
the
settings
layout,
because,
if
we're
removing
the
expand
collapse
thing
then
potentially
and
that
gets
rolled
into
it
but
like
this
is
where,
like
sometimes
I'm
like,
I,
it
feels
like
a
good
idea
and
I
don't
see
any
like
drawbacks
to
it
really
and
it's
like.
B
Do
we
just
go
ahead
with
some
of
these
changes
and
then
and
then
do
solution.
Validation
just
to
like
sense
check
it
because
from
different
scenarios
and
being
stress
tests
with
different
groups,
kind
of
explorations
with
settings,
I
feel
like
it
does,
handle
things
pretty
well
like
even
the
progressive
review
suggestion
that
eric
had,
where
you
just
click
on
it,
and
it
shows
the
ad
thing
as
like
a
nbc
move.
It's
like
yeah,
that
seems
reasonable.
Enough
is
there's
probably
some
like
tweak
some
cta
buttons,
but
other
than
that.
B
It
feels
generally
straightforward
that
a
part
of
me
is
like
we
could
go
ahead
and
create
the
issues
for
them
and
then
like
see
how
how
our
team
is
like
capability
like
in
like
how
free
people
are,
and
then
they
could
start
taking
on
these
things
or
are
we
gonna
be
strict
and
wait
for
some
feedback,
because
this
is
where
I'm
like
kind
of
balancing
between
like
this
just
makes
sense
and
let's
go
for
it
or
do
we
want
to
be?
We
should
test
everything.
What's
your
thoughts
on
that
and
katherine
and
eric.
C
Yeah,
I
I
would
say,
if
they're,
if
there's
time
to
do
testing,
then
I
think
that's
a
great
idea,
but
if
it's
more
of
a
time
crunch,
if
you
have
concepts
that
are
you're
not
as
confident
about,
I
would
prioritize
testing
that
or
even
just
internal
testing.
If
you
don't
have
much
time
to
go
beyond
that,
but
user
testing
might
also
come
in
handy
there
if
it
needs
a
quick
turnaround.
B
Yeah,
I
I
think
with
the
settings
when
some
of
the
structures
could
be
validated
even
outside
the
context
of
gitlab
right
you.
We
could
just
change
it
all
to
like
profile,
page
stuff
and
then
make
that
super
generic
yeah.
C
B
A
Right
so
we
could
change
the
patterns
on
the
merge
request
page
and
just
pay
really
close
attention
to
this
feedback,
and
if
people
are
like
what
are
you
doing
or
like
this
is
really
preventing
me
from
doing
work
or
something
you
know
along
those
lines
we
could
always
revert
and
and
regroup.
Obviously,
we
don't
want
to
mess
up
anybody's
workflow,
so,
whatever
lightweight
validation,
we
can
get
in
place.
A
That'd
be
great,
I
don't
think
we're
hurting
for
issues
for
related
to
settings
and
now
now
for
the
next
milestone,
but
these
would
be
some
of
the
more
impactful
and
welcome
changes
so
yeah.
I
think
I'll
defer
to
to
you,
michael
and
how
confident
you
and
the
rest
of
the
design
team
on
the
feedback
are,
and
you
know
never
hesitate
to
just
make
issues
and
we
can
always
discuss
whether
or
not
they
need
further.
D
I
was
going
to
mention
something,
but
eric
already
put
it
on
the
agenda
for
tomorrow's
meeting,
but
I
think
it
bears
just
briefly
mentioning
here
the
analytics
that
we're
gathering
we
still
don't
have
a
plan
of
what
dashboard
we're
going
to
capture
them
on
if
there's
an
existing
one,
if
we're
going
to
make
a
new
one.
So
just
a
heads
up
that
yeah.
We
need
to
talk
about
that
tomorrow
and
come
up
with
a.
A
Plan
yeah,
so
I
added
that
to
tomorrow's
agenda.
Hopefully
we
get
to
talk
about
it
in
depth.
I
would
propose
that
right
now,
the
the
general
trend
that
I'm
seeing
is
that
the
data
team
is
crunched
constrained,
we'll
say
and
they're
expecting
self-serve
data.
I
myself
not
proficient
enough
in
sql
to
just
like
spin
up
these
dashboards
and
run
reports
ad
hoc,
but
at
the
same
time
I
think
it's
probably
for
the
best
that
we
take
control
of
our
own
analytics
and
in
the
past,
what
I've
done.
A
A
I
realized
with
the
lag
and
data
for
usage
paying
and
for
a
lot
of
other
reasons.
That
might
not
make
sense
here,
especially
because
we
wouldn't
you
know
it
would
interfere
with
like
when
we
announced
things
in
a
release
post
and
some
other
tactical
things
with
like
how
we
ship
and
do
milestones.
So
my
proposal
would
be
to
just
have
an
epic
for
data
analysis
on
every
category
and
as
a
new,
not
new
pm,
but
as
a
as
a
newly
formed
group,
I
can
take
a
fresh
look.
What
dashboards?
A
I
would
want
to
have
access
to
per
category
and
say
you
know,
for
the
web.
Ide
I'd
really
like
to
be
able
to
see
these
five
major
things
compared
to
these
things
and
we
can
validate.
First.
Is
the
data
already
available?
Second,
and
if
not
we'll
create
issues?
Second,
is
the
dashboard
already
exists?
If
not,
we
can
create
a
dashboard
if
a
dashboard
is
needed,
we'll
create
an
epic
for
that
there'll
be
implementation
issues
as
I
get
better
at
sql,
as
I
get
better.
D
I
don't
think
it's
unreasonable
as
long
as
there's
a
defined
place,
to
put
it
to
have
that
as
part
of
the
implementation,
because
and
you
should
be
able
to
even
pre-create
it,
because
you
know
what
the
snowplow
data
is
like
in
a
known
place,
it's
in
the
known
table
and
you
can
like
pre-create
the
chart
looking
for
those
events
and
then
it's
all
ready
to
go
and
it
will
just
there's
no
more
work,
but
for
now
we
just
need
to
find
a
place
to
put
it
and
then
yeah.
We
can
move
forward.
D
You
know
maybe.
A
That's
that's
always
good,
and
and
these
these
epics
and
and
my
proposal
could
be
sort
of
limited
in
in
time
and
scope
as
well.
Until
we
get
all
these
things
stood
up
and
it'd
be
more
for
as
a
reminder
for
me
to
just
go
category
by
category
and
think
through
what
data
I
really
need
to
be
paying
attention
to.
We
have
some
of
this
already
inherited
for
some
of
the
categories
from
the
previous
incarnation
of
the
editor
group.
So
it's
not
like
we're
starting
from
scratch.
Yeah,
I
think
it'll
be.
D
Seems
like
there's
two
main
categories:
you're
talking
about
stepping
back
and
talking
about
like
strategic
data.
You
want
to
get
which
is
good,
but
I
think
this
one
was
in
the
category
of
just
something
like
ad
hoc
that
came
up
as
part
of
an
issue
and
michael
said,
you
know.
Really.
We
should
get
data
on
how
people
are
clicking.
This
thing
that
we're
talking
about
which
is
sort
of
a
different
bucket
of
stuff.
D
A
Yeah,
although
I
would
say
personally,
I
don't
want
to
advocate
for
adding
an
action
that
I
don't
have
a
meaningful
like
insight
that
I'm
hoping
to
gather
or,
like
you
know
something
where
I
want
to
measure
it
against
something
else,
like
a
raw
number
of
how
many
times,
people
click
the
more
buttons
is
only
so
helpful,
and
so
I
would
say,
for
the
navin
settings
category
specifically
like
this
would
be
an
opportunity
for
us
to
say
like
what
are
we
really
paying
attention
to
and
what
could
we
pay
attention
to
related
to
navin
settings?
A
What
are
the
areas
we
want
to
instrument
next?
What
are
the
areas
that
we
would
want
to
make
sure
that
others
instrument
correctly
when
they
take
over
the
work
so
that
we
can
just
kind
of
start
building
those
dashboards
that
are
usable
for
other
groups
as
well
in
relation
to
nav
and
settings,
but
yeah
I
mean
our
default
can
always
be
just
like
a
template
of
raw
data
and
that's
half
of
the
stacks.
A
D
Yeah-
and
this
particular
one
I
think
flowed
out
of
it's
not
necessarily
a
bug,
but
an
issue
of
people
saying
oh,
this
is
in
local
storage
and
it's
a
pain,
and
then
we
talked
about
changing
it.
We're
like
well
that's
hard.
Well,
let's
get
some
metrics
around
it,
so
it
wasn't
really
part
of
any
of
the
big
strategy
at
all.
A
Right
right,
yeah,
and
so
I
I
would
say
that
the
the
in
this
case,
the
like
the
number
count,
is
mostly
what
we're
paying
attention
to,
although
it
would
probably
be
more
useful
in
comparison
to
the
clicks
on
the
other
buttons
in
the
nav,
and
you
know
how
many
times
it's
per
unique
user
versus
raw
actions
and
things
like
that.
A
Well,
in
general,
our
our
approach
to
data
is
is
still
you
know,
evol,
it's
evolving
and
maturing,
so
we're
we're
getting
there
as
a
company,
but
I
think
we're
getting
closer
to
something.
That's
like
possible
to
self-serve,
so
yeah.
B
A
Talk
about
it
more
in
tomorrow's
meeting
a
little
bit
and
see
if
anybody
else
disagrees
or
has
other
ideas
on
how
to
implement
that.
A
All
right
that
is
about
it
and
we're
just
at
time.
So
thanks
everyone
we'll
let
michael
start
his
day
and
we'll
wrap
up
mine.