►
From YouTube: Manage::Import UX Office Hours 2021-01-12
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).
B
Yeah
I'll
do
it
if
you
like
it
or
not
so
we'll
just
go
through
the
agenda.
First
is
fy,
we're
updating
the
import
icons,
but
it's
a
little
different.
It's
not
like
a
one-to-one
change,
so
I
thought
I'd
just
walk
you
through
that.
B
All
right,
so
in
a
nutshell,
we
are
moving
away
from
the
styling
that
we
currently
have.
B
Jeremy
from
foundations
worked
on
updating
these
icons
because
he
found
that
not
just
our
team
needed
status,
icons
but
other
teams
as
well,
and
they
really
wanted
to
make
a
strong
distinction
between
pipeline
status
and
basically,
in
our
case,
import
status.
So,
let's
fast
forward.
B
Okay,
here
we
go
so
this
is
where
we're
heading
this
isn't
100
final.
Yet,
but
nonetheless,
it's
close,
so
some
wording
is
changing
and
the
big
change
actually
is
this
pending,
so
we're
essentially
combining
scheduling
and
scheduled
and
we're
changing
that
to
pending.
B
Would
that
be
a
big
deal
to
update?
I
would
assume
not
no.
A
It's
very
easy,
the
main
like
thing
which
we
will
lose,
but
I
think
we
can
live
with
that
that
it
is
understanding
like
there
is
difference
between
scheduling
a
schedule
at.
We
could
understand
like
if
this
is
at
which
step
we
fail
it
or
we
are
stuck
like
making
the
proper
request
to
the
back
end.
Initiating
the
import
or
the
import
was
initiated
successfully
and
the
stock
is
on
the
background
job
site.
But
this
is
pretty
technical
and
I
don't
feel
like.
C
Yeah
one
thing
we
actually
don't
have
scheduled
state
on
the
bulk
imports
to
begin
with,
we
have
like
started
and
sorry
created
and
started
so
there's
no
explicit
on
the
back
inside
there's
no
explicit
scheduled
state.
So
that's
probably
how.
C
As
soon
as
well
yeah
yeah-
pretty
much
I
mean
you
you
can
show
pending.
If
you,
if.
A
C
D
A
D
E
And
that's:
okay,
I
think
the
user.
I
don't
think
that
we
need
to
like
propagate
exactly
the
status.
Whether
it's
scheduled
or
started
like
pending
is
a
generic
word
that
the
users
will
always
understand
that
this
was
triggered
like
the
button
was
pressed
successfully
and
now,
but
it
hasn't
really
started
importing.
Therefore,
all
the
things
that
you
do
like
you
know
you
trigger
the
back
job,
you
schedule
it,
you
run,
it
start
it
like.
E
That's
all
your
problem
on
the
back
end
or
like
on
the
behind
the
scenes,
but
for
users
just
pending
like
hasn't,
started,
but
it's
pending
and
that's
that's
a
fair
thing
to
say
and
all
of
those
things
can
roll
up
into
it.
E
I'd
say
it's
important
for
us
to
still
be
able
to
tell
where
it
failed,
so
the
logs
should
hopefully
help
someone
look
at
seeing
well,
it
was
scheduled,
but
it
never
started
or
whatever
that
is,
but
the
user
necessarily
doesn't
need
to
see
that
this
is,
I
think,
nicer
for
the
user
and
it's
more
it's
going
to
be
able
to
be
the
same
for
all
of
our
importers
because
they
do
have
different
statuses.
Potentially,.
A
E
A
E
Yeah
it'd
be
nice
to
propagate
all
this
to
where
it
needs
to
go
to
all
the
places.
E
E
Because
we
have
the
icon
in
front
of
us
started
because
there
was
an
option
that
I
was
is
hurting
my
eyes.
A
B
E
B
Now
so
I
think
where
we.
B
How
does
this
show
up?
No,
it
doesn't
so
where
we
ended
up
is
showing
20
per
page.
B
Exactly
and
once
you
expand
that
doesn't
necessarily
count
towards
your
20
that
are
shown.
One
thing
I
want
to
show
you.
B
Let
me
think,
actually
isn't
it
harris
had
a
suggestion
and
I
think
paris
do
you
remember
when
you
brought
up.
B
I
know
like
what
did
you
say
the
suggestion?
No.
B
E
E
E
This
is,
this
is
just
like
not
necessarily
the
ui
for
it,
but
the
functionality
that
I
would
like
to
get
out
of
pagination.
So
a
more
complete
pagination
solution
and
and
and
the
most
important
thing
here
is
really
trying
to
reconcile
the
we
talked
about
kind
of
an
infinite
scroll
lazy
load
as
being
a
really
nice
way
for
people
to
see
more
things
or
to.
E
But
it
was
also
very
hard
to
reconcile
that
with
the
check
boxes
and
also
the
check
boxes
were
very
hard
to
reconcile
on
a
small
page,
because,
if
you
want
to,
if
you
have
like
100
things
and
50
out
of
those
you
need
to
do
import
on,
you
will
still
need
to
like
visit.
Multiple
pages
select,
select
from
the
top
select
all
or
select
some
of
that
and
then
go
to
the
next
page,
and
we
don't
have
a
great
way
of
understanding.
E
If,
when
you
move
to
the
next
page,
does
your
selection
carry
over
so
do
you?
Did
you
select
20
and
now
you're
going
to
the
next
page,
and
you
select
another
20?
Is
it
now
40
or
is
it
20
and
in
either?
One
of
those
solutions
is,
is
going
to
be
hard
like
we're.
Gonna
have
to
pick
one
anyway,
but
it's
it's
not
good,
because
you
know
some
users
will
assume
that
it
carries
over.
Some
users
will
not
see
it
and
assume
that
it's
not
carrying
over.
E
So
we'll
have
to
be
really
careful
with
that.
What
would
really
help
a
lot
with
alleviating
that
is
being
able
to
see
larger
pages
like
if
people
explicitly
say
I
have
a
big
monitor.
I
can
wait
five
seconds,
whatever
the
trade-offs
are,
but
I
want
to
see
100
things
instead
of
20,
because
my
total
is
100
things.
So
if
I
can
see
everything,
I
can
more
easily
pick
and
do
bulk
actions
on
it.
E
So
creating
your
own
page,
size
or
picking
your
own
page
size
is
important
and
it's
a
pattern
that
everybody
who's
doing
good
ux
actually
has
so
I
feel
like
that
is
the
most
important
part
of
this
is
really
the
page
size
selector
and
we
would
start
with
20
but
will
allow
them
to
just
go
to
like
500
all
you
know.
E
Those
would
be
like
the
options
and
all
we
may
have
a
backhand
stop
gap
on
all
as
well,
which
is
like
well,
you
know
all
really
cannot
be
more
than
thousand
or
whatever
it
is
like.
We
can
have
some
kind
of
a
limitation
that
we
will
this
describe
and
disclose
if
it
says,
if
it
returns
thousand,
it
would
just
say:
okay,
this
is
top
thousand.
You
can't
have
more
than
that.
D
A
Mean
when
we
request
you
hugest
things
of
data,
I
believe
this
is
exactly
why
every
pagination
in
gitlab
has
a
pretty
strict
limit,
I
believe
on
100
or
whatever
everywhere,
where
we
paginate
so
like.
I
I'm
a
bit
confused
with
this
straightforward
approach,
although
I
understand
your
needs,
theoretically,
we
could
automate
it
on
front-end
side
like
if
you
request
1000
items
per
page,
I
can
potentially
like
load
them
in
chunks
of
100
or
whatever.
D
B
D
B
Per
page,
so
if
I
go
ahead
and
select
all
I
get
this
banner,
letting
them
know
you
selected
50
out
of
yeah
that
many
and
then
you
can
obviously
go
in
and
deselect
or.
B
D
B
D
Page,
we
cannot
hear
you
elia,
oh.
A
Sorry
wrong
button.
I
believe
it's
maintained.
So
if
you
go
forward
and
back
it
should
it
should
keep
the
selected
check
boxes.
B
Oh,
I
see
what
you're
saying
it
works
for
me.
Okay,
I
I
thought
you
were
saying.
If
we
went
to
the
next
page,
it
would
but.
E
Going
to
be
a
problem
for
us
like
we
already
know
that,
like
you
know,
there
are
going
to
be
clients
that
are
going
to
have
thousands
and
thousands
of
projects
that
they're
going
to
want
to
bulk
migrate,
and
you
know
if
you
have
4
thousand
projects
and
we
make
them,
do
it
20
at
a
time
which
is
the
maximum
you
could
do
if
you're
going
to
pick
some
and
then
skip
some,
then
that's
still,
you
know
200
imports
that
you
have
to
do
one
page
at
a
time
like
that
is
that's
the
requirement
that
I'm
trying
to
solve.
E
D
Currently,
but
later
on,
it
won't
be
right
later
on,
they
will
be
able
to
select
subgroups,
but
besides
that,
it's
not
because
gmail
doesn't
do
that.
We
cannot
do
right.
We
could
maintain
a
status
between
base
can't
we.
E
I
think
we
should
do
that,
but
I
think
we
actually
alleviate
this
problem
a
lot
by
showing
hundred
items,
because
you
can
do
hundreds
a
time
or
potentially
you
could
do
filtering
to
bring
it
down
to
just
maybe
you
know
a
hundred
of
you
know
less
than
100
of
the
items
that
you
can
pick
from
and
then
you
select
your
75
out
of
100.
Like
you
know,
playing
with
100
is
much
easier
and
it's
going
to
solve
many
more
problems
than
playing
with
20,
because
I
believe,
there's
probably
some
kind
of
a
curve
on.
D
E
Of
this,
going
from
20
to
40
is
going
to
be
eye
opening
for
a
lot
of
people.
It's
going
to
be
so
much
more
helpful,
so
I
think
we
can
stay
on
the
low
end
of
this
and
then
serve
a
huge
number
of
people
much
better.
So
I
think
going.
If
we
cannot
do
all,
then
maybe
a
hundred
or
two
hundred,
whatever
you
said
you
said
hundred,
was
the
top
limit
that
we
are
allowed
right
now.
Well,
let's
do
that
because,
right
now
you
had
twenty.
D
D
E
Yeah,
so
the
question
is
really:
what
can
we?
What
can
we
safely
allow
like
it's
hundred
really
hundred
of
issues?
Maybe
if
you're
doing
filtering
or
you
know
so
some
table,
that's
really
huge
may
be
different
than
selecting
a
hundred
from
a
table
of
groups
which
may
be
way
way
smaller
than
number
of
issues.
So
I
don't
think
that
even
the
safety
number
is
the
same
between
the
two.
E
D
A
Yeah,
but
I
believe
just
to
make
a
check
that,
since
we're
actually
requesting
this
list
of
group
from
a
remote
gitlab
instance,
which
could
potentially
run
older
version,
if
you
do
not
want
to
overcomplicate
the
backend
at
least
for
now
as
an
iteration,
we
should
probably
stick
to
what
current
our
currently
our
api
allows.
And
if
I
remember
correctly,
the
api
is
limited
to
100
groups
per
per
page.
Correct
me
if
I'm
wrong,
yeah.
C
D
A
E
B
A
Yeah
sorry,
since,
like
amanda
said,
this
is
my
most
love
love
topic
in
the
last
discussions.
Let
me
summarize
the
action
plan
we
have
here.
So
what
we
are
going
to
have
is
a
ux,
how
we
could
want
this
pagina
this
thing
to
look
like
what
drop
down
options
do
should
we
have-
and
I
don't
remember,
do
we
have
the
backhand
support
right
now
for
pagination
there?
I
believe
it
was
there
or
am
I
wrong.
D
A
A
E
Money
to
go
feedback
on
the
component
would
be
to
maybe
see
if
we
can
stay
away
from
the
drop
down,
given
that
it's
really
a
radio
choice
of
fixed
number
of
things,
three
drop
down
requires
two
clicks
and
we
have
plenty
of
space
to
just
allow
for
for
the
choice
to
just
be
shown
there,
like
as
an
example
amanda.
E
The
the
illustration
I
gave
has
an
example
of
what
I'm
talking
about,
which
is
a
more
direct
user
experience
with
one
click
fewer
to
select
and
also
more
discoverable,
because
you
can
actually
tell
what
it
says.
You
see
there.
The
page,
selector
5,
10,
20.,
yeah,
it's
more
discoverable.
You
see
what
your
choices
are
without
engaging
a
drop
down
and
also
you
can
select
it
with
one
click
versus
two.
B
E
Selector
just
changes
how
how
big
the
page
is,
how
many
items
are
per
page.
So,
if
I
click
you
know,
five
in
this
case.
A
E
E
A
B
So
if
you
remember
from
last
week,
I
was
walking
you
through
what
andy
had
done,
so
he
is
currently
working
on
this
and
yeah.
We
certainly
can
pioneer-
I
guess
this
section
so.
B
So
should
I
okay,
so
there's
a
lot
of
ux
work
that
goes
that'll
go
into
this,
some,
not
a
lot,
but
so
next
ilya
you
would
just
need
the
final
designs
ready
to
go.
B
Yeah,
I
don't
and
I
don't
hate
the
placement
of
both
the
pagination
and
the
view
per
page,
so
I'll
work
on
that
ilya
and
then
get
that
to
you
as
soon
as
I
can
any
other
comments
about
this
and
I'll
briefly
touch
on
number
two
which
I'd
I'd
like
to
discuss
more
in
detail
next
week,
but
essentially
we're
probably
going
to
need
some
back
end
folks
to
answer
some
questions
and.
A
Yeah,
just
a
personal
request
ping
me
on
this
issue
when
there
will
be
any
progress
there,
because
it
might
impact
our
pagination
discussion.
We
had
right
now
I
mean
because
if
we
start
extracting
like
the
current
in
progress
things
to
the
top,
like
we
done
in
import
projects,
it
will
break
the
entire
pagination
flow.
A
E
I
wouldn't
change
our
approach
to
pagination
right
now.
I
think
we
have
a
good
approach
and
yeah.