►
From YouTube: Nick & Michael - Navigation concept and instance levels
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
B
Yeah,
so
I
don't
know
the
history
of
of
gitlab's
information
architecture,
but
what
I
assume
is
git
lab
was
fundamentally
built
around
the
concept
of
a
project
and,
as
such,
our
navigation
has
been
sort
of
optimized
towards
things
like
very
focused
on
the
project,
because
gitlab
came
from
source
code
management.
It
came
from
all
this
sort
of
stuff
which
sort
of
it
makes
sense
for
the
project
to
be
scoped.
B
B
Sometimes
it's
in
the
scope
of
focusing
on
multiple
projects
and
groups.
At
once,
and
then
excluding
some
other
projects
that
may
live
within
those
and
being
like
really
specific
on
the
area
that
you're
trying
to
find
some
of
the
the
customer
conversations
that
I've
had
have
shown
that
projects
and
groups
don't
typically
map
nicely
specifically
to
teams
within
an
organization.
B
So
the
challenge
we
have
within
analytics
is
there's
some
stuff
which
is
relevant
to
projects
and
groups,
but
then
there's
also
a
lot
of
stuff
which
is
relevant
to
to
the
instance
level
and
the
way
our
navigation
is
set
up
at
the
moment,
it's
quite
confusing
to
differentiate
between
projects
and
groups.
But
it's
also
feels
like
the
what,
like
the
the
metaphors
that
we
use
on
the
navigation,
make
it
feel
like
a
project,
isn't
nested
within
a
group,
and
a
group
isn't
nested
within
an
instance.
B
So
the
what
I
was
trying
to
do
was
to
make
instance
level
the
instance
like
more
of
a
concept
that
that
is
universally
understood
by
users.
So
can
we
make
the
instance
as
universally
understood
as
a
project,
and
can
we
also
tell
a
story
of
where
projects
live
in
groups
and
where
groups
live
in
in
the
instance
and
so
on?
B
So
that
was
like
the
the
general
objective
was
to
more
clearly
illustrate
the
mental
model
of
what
an
instance
is
so
we
can
more
effectively
appeal
to
the
more
senior
executive
type
people
personas,
who
use
gitlab
or
people
who
aren't
necessarily
looking
at
gitlab
from
a
project
point
of
view,
but
are
looking
at
it
from
like
a
cross
across
project,
point
of
view
or
across
group
point
of
view,
like
security
and
so
on.
So
what
we
have
in
the
nav
now
what
we
have
in
the
nav.
B
Now,
if
you
look
under
the
more
menu,
it's
essentially
all
just,
like
instance,
level
features
and
they've
fallen
under
the
more
nav
just
sort
of
because
they
don't
fit
anywhere
else
right,
so
yeah
this.
This
is.
This
is
yeah
just
something:
that's
something
that
I've
been
struggling
with
with
regards
to
like
design
and
information
architecture,
since
I've
been
in
gitlab.
So
that's
what
manifested
the
the
issue.
B
B
So
yeah
this
is
how
old
is
it
from
may?
So
some
of
the
stuff
I'm
talking
about
is
a
little
bit
dated
I'm
just
going
to
drop
this
in
the
chat,
but
it
should
give
you
an
indication
of
of
like
some
of
the
stuff
that
I
was
talking
about
and
yeah
just
take
a
look
at
that
and
as
well
as
that
yeah,
the
stop
get
that
we've
doing
been
doing
in
analytics
is
just
dropping
stuff
in
the
admin
panel,
because
admin
panel
is
effectively
instance
level.
B
So
we
originally
had
analytics
in
the
more
panel
and
then
in
order
to
drive
usage,
we
moved
it
up
into
the
navbar
and
just
had
it
as
an
icon,
and
then
sid
commented
on
it
saying:
look
you're
starting
to
clutter
the
nav
bar.
So
can
we
get
rid
of
this
and
then
at
the
stage
that
we
were
at
we
didn't?
Have
we
didn't
really
have
enough
content
with,
at
the
instance
level,
to
justify
putting
it
back
into
the
more
menu?
B
So
we
thought
rather
than
doing
that,
let's
just
put
the
instance
level
features
within
the
admin
panel
for
now,
and
then
we
can
put
the
other
features
that
don't
necessarily
need
to
be
instance,
level.
We
can
actually
just
align
those
to
group
level
such
as
productivity,
analytics
and
and
sort
of
just
work
with
it
from
that
side.
B
A
All
right,
so
one
of
the
things
that
you
propose
was
this
issue
here,
I'm
just
gonna
post
in
the
chat.
So
this
is
the
consolidating
the
menus
project
group
and
more
into
one
selection
area,
and
one
of
the
points
that
I
wasn't
able
to
pick
out
myself
was
the
one
point
in
there
around
by
making
the
change,
you're,
increasing
the
clarity
or
like
one
of
the
goals,
is
increasing
the
clarity
of
what
workspace
the
user
is
currently
in.
I
was
just
wondering
how.
B
B
Okay.
So
by
consolidating
the
the
single
project
group
and
more
experience,
it's
just
it's
it's
starting
to
make
the
concept
of
container
or
workspace
more
of
a
thing,
rather
than
I'm
in
a
project
right
now,
I'm
in
a
group
right
now,
rather
than
I'm
in
a
workspace
right
now,
and
that
workspace
happens
to
be
a
project
or
I'm
in
a
workspace.
Now
that
happens
to
be
an
instance,
or
that
happens
to
be
a
user
view
or
whatever
it
may.
B
A
Cool
okay,
and
that
makes
a
little
bit
more
sense
to
me.
Okay,
I
just
want
to
walk
you
through
one
design
that
I
have
in
my
mind
right
now,
and
I
just
wanted
to
get
your
sense
check
on
whether
this
is
like
the
right
thinking
about,
like
instance,
or
like
kind
of
the
workplace.
So
I'm
just
going
to
share
my
screen
now
and.
A
Sidebar
and
one
of
the
interesting
things
in
there
was
like
opening.
This
opens
up
like
that
that
menu
of
all
the
things
I
brought
this
up,
because
to
me
this,
I
was
kind
of
trying
to
look
for
something
like
this
in
the
other
designs
to
show
the
current
workspace
that
you
were
in,
but
I
digress
and
I'll
just
jump
into
this.
So
what
I'm
thinking
of
taking
forward
for
this.
B
A
A
What
oh
yeah
there
we
go,
so
is
this
the
right
like
is
this
wrong
to
like
think
that
instance,
level
or
like
changing
the
current
context,
to
be
using
this
kind
of
like
pattern
to
say
like
this?
Is
the
thing
that
you're
currently
in
so
it
could
be
like
project
or
group,
but
it'd
be
like
higher
level.
Then.
A
B
B
But
yeah
that
makes
sense
right
there.
It's
it's!
It's
it's
starting
to
be
a
little
bit
more
clear
of
what
is
the
work
space
I'm
in
and
what
type
of
workspace
is
it
so
instance
and
git
lab
co
is,
is
where
I'm
in
right
now
so
yeah
that
that
makes
sense
to
me
the
the
two
sidebar
approach
that
I
that
I
took
there,
I'm
not
necessarily
drawn
to
it.
B
I
just
sort
of
put
it
there
to
provide
a
little
to
to
see
if
we
could
maximize
the
vertical
space
yeah
but
again
yeah
you
sort
of
optimize
optimize
it
in
whatever
way
you
want
yeah.
But
I
think
what's
what's
nice
about
this
layout?
Is
it
sort
of
more
clearly
differentiates
the
stuff
which
is
just
mine
personally,
so
my
user
workspace
stuff.
So
my
issues
my
mind
and
then
the
shared
stuff,
which
is
like
the
the
the
instance
level
stuff.
B
A
B
B
A
Clear
what
what
this
is,
what
this
is
saying
so
that
yeah,
that
makes
sense
and-
and
I
guess
like
from
an
alignment
perspective-
it's
like
these
things-
fall
underneath
this
kind
of
pair.
So
if
I
change
this
to
a
project
and
I'll
see
like
issues
and
whatever
merge
requests,
and
things
like
that,
that
whatever
that
information
architecture
may
be
cool.
A
Cool
cool
yeah.
So
that
concludes
the
like
key
questions
I
have
for
today.
So
right
now
the
team
is
just
ramping
up
and
the
ux
research
team
is
doing
some
research
to
get
like
a
baseline
and
understanding
of
where
things
should
fit.
In
from
an
information
architecture,
standpoint
and
plus
the
current
experiences
around
settings
in
navigation
from
splitting
up
settings
and
navigation.
A
The
team
feels
like
there's
some
stuff
in
settings
that
are
kind
of
low
hanging
fruits
that
we
can
like
tackle
without
too
much
solution,
validation.
But
navigation
is
something
that
we
feel
like
needs
a
little
bit
more
solution
validation.
So
some
of
this
stuff
around
like
consolidating
the
menus,
is
kind
of
front
of
mind
to
like
tackle
very
soon
so
we're
gonna
start
taking
that
through
the
bookmarking
thing
is
a
very
interesting
thing.
A
But,
like
you
know,
my
personal
thing
is
like
yeah
it'll
be
it'll,
be
nice
to
have
bookmarking
thing,
because
my
current,
like
thesis
on
how
navigation
should
work
in
gitlab
is
that
you
should
be
able
to
navigate
gitlab
through
gitlab,
without
using
or
depending
on
browser
extensions
or
like
browser
functionality,
as
in
yeah
back
buttons
or
like
finding,
where
you
need
to
go
that
ultimately,
that'd
be
the
ideal
situation,
but
yeah
that'll
probably
take
a
while
to
get
to.
But
yeah
do
you
have
any
questions
for
me
before
we
wrap
up
today.
B
B
A
A
B
But
yeah,
I
think,
yeah.
I
appreciate
you
getting
in
touch
and
I'm
really
excited
to
see
to
see
sort
of
the
navigation
improve
in
general
within
gitlab.
With
regards
to
the
to
the
navigation
research
that
you're
doing,
I
wonder
what,
whether
so
yeah,
I
wonder
whether
there's
an
exercise
that
can
be
done
to
see
how
people
think
about
the
information,
architecture
or
hierarchy
of
of
these
key
navigation
objects,
so
understanding
people's
mental
model
of
how
they
think
instance,
level
instances,
projects
and
groups
map
and
relate
to
each
other.