►
From YouTube: Create UX catchup 11.10
Description
https://gitlab.com/groups/gitlab-org/-/boards/849335?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Create&label_name[]=Deliverable&label_name[]=UX
A
So
the
dudes,
but
everything
needed
and
the
design
tab.
This
is
pretty
well
fleshed
out.
One
thing
I
wasn't
happy
here
is
the
way
you
select
mock-ups
and
say
edit
them,
or
remove
them
or
change
one
mock-up
at
a
time-
and
this
needs
some
fine-tuning.
I
did
the
the
pattern
I
was
going
for
is
something
like
a
model
system.
So
you
have
you,
can
you
it's
it's
read-only
initially,
when
you
keep
the
edit
button,
it
becomes
editable.
The
whole
grid
becomes
editable
very
similar
to
what
you
see
on
an
iPad
or
iPhone.
A
A
Of
function-
yes,
yes,
yes,
drag
and
drop
is
something
so
today
to
speak
about
from
James
his
point
of
view.
What
he
was
thinking
was.
We
would
tackle
anything
to
do
with,
because
this
is
backed
by
git
git
LFS.
So
there
would
be
a
secondary
another
repository
in
the
project
which
stores
all
the
mock-ups.
So
what
he
was
thinking
was
we
accidentally
MBC.
A
We
would
build
all
the
git
repository
related
features
first
and
then
look
at
what
needs
to
be
done
on
the
database,
which
means
things
like
metadata,
which
is
having
a
custom
title
for
the
mock-up
or
ordering
reordering
of
the
mock-up
that
it's
not
possible
on
the
first
iteration.
So
he
wanted
to
do
that.
A
Be
keep
the
complexity,
minima
and
I
sort
of
agree,
which
is
why
we
decided
to
not
make
this
public
and
to
put
this
behind
a
feature
feature
flag
before
we
could
add
the
minimum
amount
being
ordering,
because
only
ordering
helps
a
designer
convey
a
user
story
through
this,
so
that
was
the
minimum
amount
that
I
had
said.
We
need
to
be
able
to
order,
and
in
order
to
set
the
order,
they
need
to
build
some
database
related
functionality.
A
Common
thing
was
real
a
little
interesting
because
bob
was
looking
at
it
and
he
didn't
really
have
a
solution
because
he
had
two
ideas,
which
is
either
build:
either
replicate
what
we
already
have
with
discussions.
More
use
the
existing
diff
discussions
system.
As
such,
he
wasn't
familiar
how
it
was
implemented,
and
that
was
something
he
wanted
to
explore
further
down
the
line.
Ok,
so
again,
that's
we
haven't
decided
that
yet
a
couple
of
things
we
have
decided
is
how
the
versions
are
handled.
So
every
time
somebody
changes
an
image
every
time
somebody
changes
the
order.
A
A
new
version
is
created.
So
basically,
when
the
story
changes
yeah,
when
the
title
is
changed,
I
didn't
want
to
create
a
new
version,
because
that
would
that
would
create
a
lot
of
nuisance
versions.
It
will
create
too
many
versions.
It
becomes
unmanageable
and
at
any
point
in
time
a
version
can
be
made
as
the
other
side
as
a
starting
version
is
the
very
similar
to
how
Google
Docs
yeah.
B
A
A
A
A
And
this
covered
message
you
would
also
go
and
go
and
and
it'll
help
start
the
discussion
it'll
go
into
the
discussion
tab
as
a
as
a
new
discussion.
So
all
that
made
sense
so-
and
this
part
is
done,
which
is
creating
a
creating
discussions
on
this
needs.
Some
fine-tuning
little
tails
clicking
on
the
issue.
A
I
didn't
go
for
things
like
rectangular
or
you
know
some
kind
of
markup,
because
I
there
are
some
tools
in
which
you
can
draw
a
rectangle,
and
that
area
is
highlighted
as
an
annotation
and
I
want
to
make
that
all
that
complications.
This
is
just
tap
to
start
to
start
a
conversation
on
that
spot.
I
am.
A
Just
a
single
point:
okay,
okay
I
mean
from
an
implementation
point
of
view,
because
initially
I
spoke
to
a
couple
of
front-end
engineer.
Paul
slaughter
was
supposed
to
work
on
this,
this
model
interface
and
he
also
raised
some
concerns
on
how
much
we
can
build
in
a
single
milestone.
So
that
was
something
that
influenced
some
of
the
decisions,
and
this
numbering
is
basically
a
way
to
keep
track
of
the
conversation,
because
the
conversation
doesn't
really
have
a
starting
point,
so
that
is
sort
of
like
a
conversation
idea,
kind
of
anything.
A
A
And
I
guess
that's
it,
so
this
would
need
some
yeah
again,
so
this
would
need
some
UI
fine-tuning
like
what
the
cursor
should
look
like
and
the
this
still
doesn't
have
the
the
more
button
which
has
delete
and
other
into
other
things,
and
the
thing
is
this:
should
open
fullscreen.
That
was
one
thing
that
I
was
very
adamant
about
with
James.
It
should
hide
all
Keebler
branding.
That's
the
only
way
to
give
enough
real
estate
to
show
some
mock-ups
here
there
was
something
and
I
think
this
is
a
good
foundation.
A
B
B
My
second
question
was
so
I
can
I
can
understand
that
in
the
discussion
thread
chronologically,
you
want
to,
you
know,
see
like
hey.
This
is
version
twenty
years,
nineteen
kind
of
discuss
changes,
but
in
the
description
it
would
be
nice
if
you
can
always
see
the
latest,
leaving
version
with
the
complete
story
right.
A
Yeah,
no,
no,
not
at
all
you
know,
yeah,
it's
just
like
the
changes
tab
in
the
merge
request.
Page,
you
only
see
what
is
latest
and
when
you
open
something
and
or
when
you
change
the
version.
This
is
roughly
the
how
the
changes.
Tab
itself
is
right,
like
I
mean,
have
a
versions
drop
down
and
change
the
version.
So
that's
it.
That's
done
so
it's
still
familiar
one
other
thing
that
I
experimented
upon,
but
we
didn't
add
it
into
this
was
this
was
something
that
me
and
James
had.
A
So
can
you
see
my
sketch
window
yeah
yeah,
so
this
was
one
of
the
alternatives
that
I
had
proposed
to
the
design
tab,
which
is
like
a
design
section
as
part
of
the
description,
this
this
I
felt
was
was
a
better
solution
because
it
kept
a
source
of
truth
closer
to
the
description,
and
we
had
a
lot
of
discussion
around
this,
but
he
felt
a
design.
Tab
was
stronger.
We
never
really
settled
this
argument,
but
maybe
I
would
love
to
hear
what
you
mean
if
you
have
a
different
idea
on
that
or.
B
B
A
A
B
B
B
A
B
A
B
A
A
A
It's
it's
on
my
end,
I'm
actually
moving,
and
so
most
of
the
most
of
my
stuff
are
packed
and
I
got
another
another
week
here,
yeah
anyway,
so
something
what
me
and
James
were
discussing
where
a
UI,
exactly
like
this
below
the
Mara.
That
would
display
the
order
in
which
the
merge
request
gets
gets
merged,
which
would
mean
the
sum
of
the
use
case
would
be
highlighting
which
mirja
quest
we
were
in
when
it'll
be
executed,
or
scenarios
like
when
there's
a
pipeline
failure
and
the
purge
stops
how
to
handle
that.
A
Those
are
the
tricky
thing,
tricky
things
one
you
a
UI
expression
that
this
was
something
we
discussed
in.
The
meeting
which
I
didn't
have
time
to
prototype
was
something
like
a
mini
pipeline
camp
graph.
We
could
the
mini
pipeline
graph
pattern
and
adopt
it
to
because
the
merge
order
is
linear,
there's
never
going
to
be
any
branching
in
it.
We
could
show
something
like
that
for
for
merge,
quests
by
magnet,
so
that
that
was
and
by.
B
A
So
we
we
got
rid
of
that
because
originally
that
was
intended
for
VMware
and
there
when
they
started
discussing
about
it,
the
the
scope
became
really
overblown.
So
anything
to
do
with
the
all
the
super-murderer
requests
issues,
they're
all
pretty
much
dead
and
james
really
doesn't
want
to
build
something
really
really
complicated.
So
we're
we're
only
going
to
look
at
this.
First
merger
merge
order,
and
this
would
and
jamie's
confident
that
this
will
solve
our
problem,
which
is
handling
the
different
projects
that
good
luck
has.
A
B
In
from
my
understanding
right,
one
of
the
problems
that
we
have
and
which
I
was
explained,
but
I
think
that
it's
also
stated
here
is
that,
if
I
create
two
merged
quests
in
two
different
projects
and
I
want
them
to
be
reviewed
because
they
fix
the
same
issue.
You
know
like
it's
my
shoe,
that
has
to
merge
question
to
different
project
yeah.
B
A
B
A
Version,
but
as
far
as
the
review
is
concerned,
one
of
the
things
that
we
were
just
I
da
ting
was
having
reviewing
the
action
of
reviewing
like
a
task
right
now.
We
communicate
reviewing
by
assigning
the
merge
request
to
somebody
you're,
like
passing
the
ball
to
the
next
person,
asking
them
to
review,
maybe
instead
of
using
the
assignee
field,
because
we
there's
there's
a
there's,
a
issue.
I
found
to
have
multiple
assignees
for
a
merge
request,
and
when
that
happens,
this
little
trick
doesn't
work.
A
So
we
could
add
another
field
there
as
a
reviewer
field,
so
whose
review
is
pending
and
maybe
make
review
into
some
kind
of
a
workflow
that
that
would
that
requires
very
holistic
thinking
and
and
James
wasn't
really
clear
whose
stage
group
this
would
belong
belong,
and
so
we
were
just
I
dealing
there
and
that
would
that
is
anyway
independent
of
this
particular
problem.
That
is
thinking
of
review
as
a
higher
concept.
A
A
A
A
A
A
B
A
Yeah,
that's
that's
a
really
crazy
situation,
and
another
thing
we
were
worrying
was
whether
to
make
this
a
default
feature,
because
99%
of
the
teams
won't
mean
something
like
this,
and
this
is
only
used
by
really
really
big
companies
who
have
so
many
distributed
projects
coming
together
to
be
a
single
product.
Yeah.
A
This
is
something
new
and
James
didn't
have
a
clear
idea
on
where
to
put
this
feature
in,
and
one
thing
I
proposed
was
to
hide
this
in
the
project
settings
because
say
only
1%
of
the
users
need
it.
So
why
make
it
default
was,
but
his
argument
was,
if
we
don't
make
it
default,
how
will
people
discover
it.
B
A
B
B
A
Couple
of
things
that
most
of
the
things
have
been
implemented
already
and
one
of
the
things
that
James
wanted
to
dive
deep
into
was
the
discussions
tab
a
way
to
to
highlight
unresolved
discussions
easily.
We
currently
have
this
button
right,
the
go
to
the
next
resolved
discussion
button
and
that
that
usually
doesn't
work.
It's
it's
sort
of
unpredictable,
sometimes
worse,
sometimes
doesn't
work
and
I'm
not
able
to
reproduce
the
when
it's
not
working.
A
So
this
was
one
thing,
the
the
sidebar
idea.
Yes,
it
might
work
and
I'm
still
on
the
on
the
wall
about
how
this
should
be.
Maybe
it
should
be
a
sidebar
or
maybe
it
should
be
like
a
bottom
bar
that
we
already
have
for
batch
comments.
It
could
be
something
like
that
where
you
can
have
the
next
and
previous
button.
A
A
A
B
So
because,
when
looking
at
the
board
for
an
eleventh
of
ten
for
create
and
UCSC
edited
project
in
wippid
need
and
fork,
but
it's
nice
shortcut
create
much
less
from
what
I
ve.
Also
nice
web
ID
allows
file
names
ending
with
space
with
three.
We
might
see
multiple
discussions,
relying
much
less
tips.
This
is
something
that
I
see
that
was
already
some
old
UI
by
Atari
and
and.
A
Actually,
really
like
Tori's
idea
here,
and
this
really
is
the
I
mean
we
would
have
to
think
about
this
parallely
with
how
we
would
do
range
comments.
That
is
another
thing.
That's
in
James
radar,
which
is
range
comments.
It's
like
you
could
select
a
set
like
a
start
and
end
for
your
comments,
and
that
becomes
the
order
say
that
that
becomes
the
annotation
point.
Instead
of
a
single
line,
you're
annotating
a
set
of
lines,
oh.
A
Don't
know
James
would
definitely
have
a
sample
project
under
the
world,
so
I
even
Jarret
does
that
so
you
could
select
you
what
they
do
is
on
the
line
number.
You
can
drag
and
select
a
bunch
of
lines
and
it
becomes
the
starting
point
of
the
conversation.
That
is
also
that
opens
up
a
situation
where
you
could
have
overlapping
sets.
B
A
A
Very
hard
to
support
mobile
and
I
and
there's
a
lot
of
it's
it
fits
into
a
lot
of
gray
area
like
I.
Could
it
could
be
right
could
be
wrong?
Maybe
some
user
research
would
help
on
what
this
intuitive
here,
because
it's
very
easy
to
take
some
already
existing
solution,
but
still
abusers,
won't
understand
how
it's
there
and
and
we'd
have
to
make
it
work
everywhere.
It'd
have
to
work
in
the
comments
page
had
to
work
in
there,
every
every
page
that
has
a
disk
yeah.
A
B
A
So
this
was
very
ideas
he
wanted
to
make
commits
you.
You
should
be
able
to
add
a
comment
on
the
commit
message
itself.
It's
not
likely
so
in
a
merge
request.
Page
currently,
new
commits
are
shown
as
system
notes,
so
it
could
contain
like
a
like
an
icon
button
to
start
a
comment
there
and
that
could
open
up
a
new
conversation.
That
was
some
of
the
some
of
the
ideas
that
we
floated,
but
we
do.
B
A
A
very
minimal
thing,
but
it
has
value
to
some
extent
yes,
and
we
could
even
do
that
to
system
notes.
I
mean
I
mean
one
of
the
things
that
really
liked
it
slack
is
the
bot
messages
or
simple
things
like
somebody
leaving
or
joining
those
are
all
so
reactive,
and
that
adds
so
much
emotion
to
the
conversation
that
that's
something
we
should
try
to
capture
in
the
discussion
time.
A
A
This
was,
we
didn't,
have
much
discussion
on
this
other
than
and
the
fact
that
this
would
be
inside
the
web
ID
and
simply
because
we,
the
DA
way,
didn't
really
have
any
concrete
solution
to
do
web
sockets.
We
would
need
all
the
web
sockets
power
to
implement,
chat
and
live
coding.
Shaq
was
also
discussed.
We
here,
but
we
thought
of
going
with
live
well,
live
coding
first,
before
we
get
into
any
kind
of
text
chat.
A
But
that
is
something
that's
something
we
don't
know
like.
The
design
management
is
going
forward,
so
I,
don't
I'm,
not
sure
how
James
would
prioritize
between
design
management
and
live
could
live.
Coding
was
originally
in
the
mail
in
the
roadmap,
but
design
management
just
came
out
of
nowhere,
and
we
had
to
prioritize
that
and
another
thing
that
took
a
backseat
was
improvements
to
wiki
and
snippets
yeah.
B
B
A
Would
also
bring
in
I
mean
if
we
could
make
that
it
would
make
out
adding
authorization
very
easy
that
would
make
organizations
set
up
the
keys
internally
keys
that
can
really
go
up
against
confluence.
Confluence
was
the
name
that
was
thrown
around
a
lot
during
my
discussion
with
James.
But
change
was
a
little
scared,
because
the
moment
you
are
having
confluence
as
something
you
are
aspiring
to
you,
you
will
add
a
lot
of
unnecessary
features
and
he
wanted
to
keep
it
close
to
get
as
possible.
A
B
Yeah
sounds
good
I.
Think
I
will
have
a
discussion
with
James
as
well
to
see
like
hey.
What
is
the
actual
thing?
What
is
going
to
be
put
into
level
10?
You
know
think
they
it
was.
Let's
set
settle
down
on
the
exact
Scopes
were
intending
for
implementation,
and
a
little
tendency
would
be
temple
is
home
as
much
as
possible
yeah,
but.