►
From YouTube: GitLab object model - napkin sketch v1
Description
Nick takes an initial stab at creating an object model for GitLab and showing how the Manage:Analytics uses this model to inform their UX strategy.
Object model issue: https://gitlab.com/gitlab-org/gitlab-design/-/issues/789
Object-oriented analytics issue: https://gitlab.com/gitlab-org/gitlab/-/issues/205348
A
Hey
team
I
wanted
to
give
you
a
quick
overview
of
what
objects
are,
how
they
apply
to
get
lab
and
then
how
you
can
use
objects
actually
to
inform
your
UX
strategy.
So,
let's
start
out
by
just
quickly
jumping
into
what
an
object
is
so
an
object
is
like
a
typical
pattern
that
we'd
find
at
a
high
level
within
the
product
and
an
object
is
made
up
of
different
regions
and
regions
are
made
up
of
different
components
and
components
are
made
up
of
different
foundations.
A
So
we
have
an
object
which
could
be
something
like
an
issue.
An
issue
then
is
broken
down
into
multiple
regions
like
say
a
page
header
and
a
filter,
and
then
page
headers
and
filters
can
be
broken
down
into
little
components
like
buttons
or
dropdowns,
and
then
components
can
be
broken
down
into
things
like
the
colors.
The
typeface
things
like
that,
so
each
object
has
a
specific
purpose
which
is
linked
to
one
or
a
few
jobs
to
be
done,
and
that
object
is
optimized
towards
fulfilling
that
job
to
be
done.
A
So
an
M
R
object,
one
of
the
key
jobs
to
be
done.
There
would
be
around
making
a
change
to
the
code
base
and
then
collaborating
around
that
change,
so
each
object
is
very
much
focused
on
a
specific
job
to
be
done
and
allowing
users
to
achieve
that
goal
as
effectively
as
possible.
So
if
we
apply
this
thinking
to
get
lab
call
that
section
Naomi.
A
If
we
apply
that
section
that
thinking
to
get
lab,
we
can
think
about
the
core
sort
of
workflow
objects
in
get
lab
is
like
a
user
and
then
a
a
repo
which
is
the
you
know.
The
codebase
holds
the
code
and
then
we
have.
If
the
user
wants
to
make
a
change
to
the
code
base,
they
would
maybe
create
a
M
R
and
use
that,
mr
to
collaborate
with
some
peers,
some
other
users
around
that
change
and
then
finally
integrated
in
the
codebase
and
ship
it
and
deploy
it
to
their
infrastructure.
A
And
if
they
wanted
to
talk
about
some
more
broad
issues
or
plan
their
work,
they
could
potentially
use
issues
as
an
object
to
do
that.
And
then
the
workflow
for
issues
would
look
something
like
a
user
creates
an
issue
they
discuss
and
collaborate
within
the
issue
and
that
issue
been
broken
down
into
multiple
MMR's,
which
were
then
shipped
to
the
repo.
Now,
if
you
extrapolate
this
and
say
we
have
a
thousand
users
and
those
a
thousand
users
are
creating
10,
M,
R's
and
10
issues
and
all
that
sort
of
stuff.
A
A
That
help
us
to
organize
all
this
information.
That's
happening
right
now
with
the
users
okay,
so
we
have
this
core
workflow
right
here
we
have
our
organizational
objects,
and
now
we
need
to
help
users
track
and
improve
their
workflows
and
customize
it
in
ways
that
are
that
are
meaningful
for
them.
So
we
do
that
with
with
tracking
objects.
A
So
labels
gave
users
flexible
ways
to
tag
and
manage
the
different
workflows
happening
within
here
and
make
it
their
own
milestones,
sort
of
scope.
The
work
happening
within
a
particular
time
frame
and
epics
scope,
the
the
work
around
a
particular
topic
or
initiative,
and
these
are
tracking
objects,
as
I
talked
about
and
then
finally,
we
have
the
users
working
on
all
this
sort
of
stuff
they're
able
to
organize
their
information
effectively
projects
and
groups
and
they're
able
to
track
their
workflows
effectively
with
these
tracking
objects.
A
A
A
So
this
is
visualizing
information
at
different
levels
of
abstraction
to
allow
users
to
spot
patterns,
but
also
allowed
them
and
enable
more
interesting
workflows
like
we
have
within
within
the
the
Kanban
board.
So
how
does
analytics
use
the
object
model
to
inform
their
UX
strategy
and
plan
their
work
under
the
change
to
a
nice
little
color.
A
The
region's
will
inform
what
components
are
needed
and
the
components
will
inform
what
sort
of
foundations
are
needed.
So
there's
this
nice
sort
of
top-down
and
bottom-up
action,
that's
happening
by
collaborating
between
stage
groups
and
foundations,
team
and
the
analytics
team,
is
gonna,
focus
and
prioritize
our
work
by
focusing
on
these
two
objects
right
here,
the
report
and
the
dashboard.
A
So
by
creating
the
report
in
the
dashboard
objects,
we
will
get
a
better
understanding
of
what
what
the
components
and
what
regions
are
needed
to
support
gitlab
as
a
whole
for
more
generic
context
and
then
finally,
we're
also
focusing
on
the
value
stream,
and
we
can
think
about
the
value
stream
as
basically
this
little
workflow
here
and
that
workflow
the
value
stream
and
then
there's
some
fancy.
Ci
CD
magic
going
on
to
deploy
the
stuff
is,
is
what
we
call
a
value
stream,
and
this
entire
workflow
generates
a
lot
of
data.
A
So
that's
it.
We
have
workflow
objects,
we
have
organizational
objects
and
we
have
tracking
objects,
as
well
as
visualization
objects,
to
help
users
to
achieve
their
workflows
and
collaborate
with
one.
Another
objects
are
composed
of
different
regions
and
components
and
foundations,
and
you
can
use
this
object
model
to
think
about
where
you
invest
your
effort
as
a
stage
group
in
order
to
prioritize
what
sort
of
what
sort
of
component
work
you're
contributing
to
the
design
system,
we'll
get
you
and
the
rest
of
gait
lab
team
members,
the
most
bang
for
their
buck.