►
From YouTube: Group Design Feedback - Web IDE
Description
The UX team reviews and discusses the proposed strategy for the direction of the Web IDE.
A
B
B
So
what
I'm
going
to
be
talking
about
today
is
the
web
IDE
and
especially
more
into
the
direction
of
strategy
and
vision.
There's
been
a
lot
going
on
with
the
web
IDE
and
there's
not
gonna,
be
really
many
designs.
Today,
it's
more
about
like
high-level
strategy,
but
let's
get
right
in
so
when
I
started
working
in
the
editor
book,
the
web
IDE
was
in
a
state
where,
due
to
the
infrastructure,
any
new
planned
features
couldn't
actually
be
implemented.
B
The
infrastructure
was
in
a
state
where
the
setup
we,
which
shows
a
couple
of
month
ago,
didn't
make
sense
anymore
for
any
of
the
new
features
that
were
being
planned.
This
came
up
in
a
couple
of
different
cases,
and
so
the
team
decided
to
check
out
a
couple
of
different
options,
and
most
of
them
were
actually
third-party
tools
and
see
whether
we
might
switch
over
the
entire
web
ite
architecture
to
one
of
the
open
source
alternatives
and
the
one
option
that
stood
out
in
the
end
was
fair.
B
It's
a
third-party
tool
and
it
was
chosen
to
do
a
back
end
proof-of-concept
around
it
and
see
whether
implementing
this
would
make
more
sense
than
continuing
to
build
our
own
solution
and
see
whether
we
can
actually
build
all
the
stuff
that
we
already
planned
to
implement
in
the
web,
ID
in
FEA,
for
or
with
less
effort
and
still
maintain
the
same
kind
of
closeness
and
it
being
implemented
and
integrated
into
the
gait
lab.
Ui.
B
This
was
done
about
eight
months
ago,
there's
not
much
the
ex
involvement
in
the
beginning,
so
this
entire
back-end
PLC
happened
entirely
only
due
to
the
infrastructure
problems.
So
when
we
joined
and
me.we
is
the
PM
Kai
and
me,
we
also
had
a
look
at
the
persona
and
the
stage
direction,
because
the
web
ID
already
evolved
over
the
time
the
initial
idea
of
the
web
ID.
As
you
can
see
here,
it
was
built
by
Jakob
shots
as
the
first
proof
of
concept
and
was
really
focused
on
non-technical
users.
B
It
was
really
focused
on
making
small,
simple
changes,
and
we
already
went
way
further
than
that.
The
current
strategy
is
already
way
more
focused
on
anybody
who
works
in
source
control
projects
and,
most
of
me,
that's
also
engineers
and
you
to
get
lab.
Having
way
more
engineers,
who
also
have
great
ideas,
what
you
can
load
into
a
web
IDE
and
to
make
or
put
a
lot
of
effort
into
coming
up
with
new
ideas
how
this
can
work
in
even
more
great
ways.
B
We
already
built
a
lot
of
engineer
focused
features
into
the
web
IDE,
even
though
in
the
beginning
it
was
focused
on
non
edginess,
and
this
becomes
especially
clear
if
you
look
at
the
complete
maturity
chart
when
you
look
at
the
kind
of
features
that
we
wanted
to
build
in
together
from
viable
to
complete,
you
will
see.
All
of
this
is
way
more
engineer
and
developer
focus
than
anything
else.
B
Luckily,
there
was
already
a
u.s.
UX
research
session
coming
up
that
we
had
planned
and
we
used
this
as
some
kind
of
a
benchmark.
We
wanted
to
get
users
with
a
complete
flow
of
forking,
making
changes,
adding
a
file
committing
creating
numerous
requests.
We
wanted
to
see
how
tough
is
that
and
the
results
were
quite
troublesome
because
from
the
5
users
we
had,
all
of
them
were
technical
people.
Only
three
of
them
were
able
to
complete
the
entire
flow
successfully.
B
So
this
already
was
a
problem,
but
we
still
went
ahead
and
looked
at
if
we
implement
failure.
How
much
can
we
actually
customize?
How
much
can
we
actually
put
it
into
the
get?
Let
you
I?
How
much
can
it
actually
be
part
of
get
lab
instead
of
something
that
like
lives
away
from
it
and,
together
with
Carl
I,
looked
at
a
couple
of
different
things
that
maybe
would
have
made
sense?
It
was
not
anything
where
we
already
knew.
This
is
exactly
what
we
want
to
build.
B
B
We
also
looked
at
how
much
can
we
implement
get
lab
UI
components
into
Thea
to
make
sure
that
not
only
are
we
still
are
we
still
implementing
pajamas
components,
but
also
how
like
what
kind
of
implications
would
that
have
for
Thea
actually
and
for
the
use
test?
Editors
and
after
we
took
all
these
information
from
the
research
from
the
backend
PLC
from
the
front
and
PLC,
we
took
a
step
back
and
looked
at
what
design
problem
are
we
actually
solving
and
the
big
one
that
came
up
was
really.
B
B
It's
allowing
developers
to
switch
from
local
IDs,
like
vs
code
to
the
web
ID
and
together
with
that,
there
are
some
challenges,
as
you
saw
using
failure
as
web
ID,
because
there
was
no
way
due
to
the
UI
that
it
uses
due
to
the
kind
of
complexity
that
it
has
and
also
due
to
security
and
certain
architecture,
decisions
that
we
can
actually
integrate
it.
Just
as
the
web
ID
into
the
gitlab
framework.
B
It
also
has
way
longer
start
of
China
and
that
all
means
that
the
workflow
also
has
to
change
completely
for
how
we
want
to
involve
the
web
ID
into
the
workflow.
If
we
go
with
theá--.
So
all
of
this
means
we
would
have
a
fundamental
shift
in
vision
and
target
group
for
the
entire
web
ID
category,
and
we
solved
this,
and
at
least
this
is
now
our
idea.
By
splitting
it
into
two
different
experiences.
B
We
are
going
to
use
the
old
web
ID
as
we
call
it
we're
going
to
continue
to
use
it,
but
as
a
multi
file
editor,
we
are
going
to
make
it
even
easier
to
use.
We
are
going
to
pull
out
features
that
have
already
been
implemented
and
that
are
confusing
to
users
and
really
hyper
focus
it
on
small,
quick
changes
that
are
supposed
to
be
done
by
anybody,
whereas
Thea
as
a
new
web
IDE
is
supposed
to
be
for
developers,
it's
supposed
to
compete
with
the
desktop
ID.
B
It
actually
should
do
so,
and
it's
not
integrated
as
much
into
the
workflow.
It's
more
like
you
have
a
separate
tab
open.
You
continue
to
use
it
as
your
daily
use
as
your
daily
IDE
tool.
Our
main
idea
is
to
make
it
a
standalone
app,
that's
still
integrated
into
the
workflow,
but
it
lives
in
its
own
tab.
You
can,
for
example,
reach
it
via
IDE
dot,
git
lab
comm.
B
It
still
follows
the
pajamas
principles,
but
it
uses
other
UI
components
because,
as
you
saw,
an
IDE
has
a
very
different
kind
of
use
than,
for
example,
a
web
get
let
yes
and
so
to
take
this
into
account.
We
saw
in
the
front
and
POC
it
just
didn't
make
sense
to
take
overall
the
exact
same
kind
of
components,
behaviors
patterns.
We
would
have
to
be
focusing
in
a
bit
more
on
what
does
in
IDE
actually
need,
and
you
can
see
the
difference
between
the
old
web
IDE
and
the
new
web
IDE
very
well.
B
When
you
look
at
the
goal,
our
goal
for
the
old
web
IDE
is
to
open
it
cry
it
off.
We
want
users
to
go
in,
make
a
change
close
it
again,
that's
perfect!
If
we
can
get
users
to
continuously
make
small
changes
in
the
web
ID.
This
is
exactly
what
we
want.
We
want.
There
were
many
different
sessions,
but
each
with
a
soft
short
session
time,
whereas
the
Thea
new
web
IDE
is
supposed
to
stay
open
in
a
separate
tab.
B
It's
supposed
to
be
the
IDE
that
the
developer
works
in
doing
a
lot
of
different
reviews.
Doing
a
lot
of
different
merge
requests.
We
want
the
KPI
to
be
long
session
times.
I
can
also
already
give
you
a
couple
of
small
details
around
this
multi
file,
editor
vision
that
we
have,
but
because
I
have
already
spoken
for
way
too
long.
B
The
web
ID
is
something
that
touches
a
lot
of
other
stages.
We've
already
had
contact
with,
for
example,
Demetri
around
verify,
so
one
feedback
I
would
love
to
hear
is
how
would
this
really
affect
the
experience
in
another
stage
group?
Would
it
affect
that
at
all
and
also
more
on
strategy
and
the
vision
of
it
not
so
much
about
designs,
because
the
designs
I'm
going
to
show
are
completely
in
a
very
early
state
and
I'm,
not
even
going
to
be
like
I
even
have
started
working
on
them?
B
C
Clear
I,
so
my
first
piece
of
feedback
is
I.
I
love
the
story
that
you
tell
and
very
clear,
very
rational
way
of
of
talking
about
the
problem
and
then
and
then
finding
what
potential
solutions
and
options
are
out
there
I
think
with
regards
to
the
new
vision,
something
that
is
an
interesting
area
to
explore
is
around
how
you
position
these
two
separate
value:
propositions
within
the
context
of
the
broader
product
and
I.
Think
that's
that's
a
potential
research
stream
that
you
may
want
to
investigate,
so
ya!
B
Make
sense
absolutely
and
I'm
actually
going
a
bit
more
into
the
especially
the
business
and
use
cases
for
the
new
F
IDE
at
the
end
of
this,
but
you
bring
up
great
point
and
we
are
still
in
the
face
where
this
is
not
completely
fixed,
where
this
is
all
under
discussion,
and
so
this
is
a
great
point
to
bring
up
yeah.
Thank
you,
cool,
hey,.
D
Marcel
one
thought
that
comes
to
mind
to
me
is
for
secure
and
defend.
There
might
be
opportunities
where
we're
gonna
start
leaving
features
throughout
the
entire
application,
and
one
of
those
areas
may
be
the
web
IDE.
How
do
we
plan
to
manage
or
what
are
your
thoughts
around
managing
which
IDE
do
things
go
into,
and
will
we
run
into
situations
where
we
need
to
build
it
in
two
places?
D
B
I,
don't
hope
so.
I
also
have
something
coming
up
here
and
maybe
I
should
actually
finish
the
entire
session
from
the
presentation
first,
so
that
I
can
go
into
all
of
this.
But
our
hope
is
also
that
we
can
duplicate
the
single
file.
I
did
assume.
This
is
something
that
was
planned
before
already
and
actually
moving
the
multi
file.
Editor,
the
old
web
IDE
back
from
a
future
level
and
making
it
simpler,
easy
to
use
would
actually
help
us
with
replacing
the
single
file
editor.
B
So
our
hope
is
to
make
the
multi
file
editor
of
the
old
web
IDE.
The
only
real
editor
that's
available
in
the
get
lab
UI,
whereas
the
failure
web
ID
is
really
something
that's
kind
of
a
related
product,
but
it
lives
outside
of
the
gates
of
UI
and
I
can
show
actually
a
short
demo.
How
something
similar
could
look
like
later
I'm
quickly
going
to
finish
the
presentation,
because
I
always
see
a
couple
of
questions
could
be
answered
by
some
of
these
aspects
that
are
coming
up.
B
So
some
of
these
features
that
we
are
considering
we're
moving
from
the
web
ID,
for
example,
the
staging.
This
is
something
that
a
lot
of
a
lot
of
problems
in
the
entire
workflow
of
the
web
IDE
even
for
experienced
developers
we're
going
to
check
whether
we
want
to
remove
the
pipeline
view
the
review
tab-
and
this
is
something
where
I'm
not
quite
sure
off,
but
we
are
also
considering
removing
the
terminal
again.
What
we
instead
want
to
add
is
a
merge
request
flow
inside
the
web
IDE.
B
B
So
we
are
going
to
have
regular
user
research
sessions
with
target
users,
we're
going
to
try
whether
we
can
use
users-
maybe
a
tough
word,
but
let
the
new
hires
help
us
to
see
what
the
experience
is
for
someone
who
has
never
worked
in
the
web
IDE
when
they
join
and
when
they
have
to
do
some
kind
of
handbook
test
when
they
have
to
add
themselves
to
the
team
page.
This
is
something
where
we
want
to
continuously
have
a
benchmark
for
ourselves.
B
Are
we
still
solving
for
these
kinds
of
target
users,
or
are
we
already
going
again
into
more
of
the
developer
experience
to
problems
that
we
are
still
figuring
out
right
now
is
mobile
support.
The
web
ID
currently
is
not
great
for
mobile,
it
kind
works,
but
it
also
doesn't
so
we
have
to
look
into
how
we
can
solve
that,
and
the
second
part
is
what
I
mentioned:
replacing
the
single
file
editor.
B
If
I
can
quickly
show
what
the
current
version
of
the
web
IDE
looks
like
I
hope
you
can
all
see
it
on
your
screens.
Maybe
I
can
zoom
in
a
bit.
Let
me
quickly
see
when
I
can
go
out
here.
So
one
part
that
I
really
want
to
get
rid
of.
Is
this
staged
changes,
area
and
state
changes
staged
changes,
the
users
just
didn't
see
it
didn't
understand
it.
We
can
make
this
way
clearer
if
we
just
from
the
beginning
on
get
rid
of
staging
at
all
and
move
to
just
changes.
B
B
The
main
adventures
in
use
cases
and
this
speaking
to
what
make
mentioned
earlier,
what
is
the
new
web
ID
actually
supposed
to
do?
We
want
to
have
an
IDE
that
can
compete
with
the
local
IDs
and
have
the
big
advantage
of
not
having
to
install
all
your
dependencies
not
have
to
depend
on
a
certain
kind
of
operating
system.
It's
just
starting
up
the
browser
working
in
it
and
it
directly
works.
B
You
can
see
your
changes
and
I
can
show
a
quick
demo
of
how
this
actually
works
with
Thea
itself
and
a
product
that
they
build
themselves,
which
is
called
get
pod.
So
you
have
this
project
here.
This
is
something
that
could
be
hosted
on
github,
you
started
and
you
see
this
is
its
own
UI.
It's
looking
very
similar
to
vs
code.
That's
because
it's
built
on
the
same
kind
of
platform
and
you
can
change
the
code
and
you
directly
have
live
preview.
You
can
even
open
a
separate,
app
and
see
it
in
here.
B
It
directly
works.
You
can
directly
see
the
changes.
This
is
the
kind
of
experience
we
want
to
enable,
and
all
of
this
has
the
big
advantage
of
not
having
to
deal
with
all
the
dependencies
that
can
really
take
a
lot
of
time.
A
lot
of
complexity.
All
of
this
also
enables
us
to
push
more
code
into
the
cloud.
B
Additionally,
it's
built
on
the
escort
platform,
so
that
means
we
have
access
to,
for
example,
all
the
plugins
themes,
so
that
we
can
use
this
to
enable
new
features
rather
quickly.
One
thing
that
we
already
looked
into,
for
example,
was
live
collaboration.
There
already
is
a
way
in
thea
to
work
on
code
like
in
Google
Docs.
B
C
That
wasn't
making
fun
of
your
presentation,
but
thinking
about
the
best
way
to
present
these
value
propositions
to
users
and
getting
getting
feedback
from
that
perspective
may
be.
It
may
be
quite
interesting,
but
yeah
love
it
and
I,
especially
love
the
the
strategy
around
new
joiners.
Getting
feedback
like
consistent
flow
of
feedback.
B
Yeah
and
I
can
also
say
if
I
go
back
to
the
UX
research.
One
aspect
that
helped
tremendously
doing
all
of
this
was
that
both
Kai
and
me
were
in
the
actual
UX
research
sessions.
Catherine
was
incredibly
helpful
in
setting
all
of
the
sessions
up,
but
it
was
so
tremendously
helpful
to
have
kai
in
there
as
a
p.m.
to
see
what
the
actual
experience
is
to
see
what
users
are
struggling
with.
E
While
you're
talking
on
that,
because
you're
talking
exactly
on
the
point
and
I
had
a
little
bit
of
questions,
first
of
all,
I
think
great
demo.
Thanks
a
lot
and
my
question:
was
you
mentioned
that
you
tested?
You?
Did
the
research
with
five
participants
and
you
said
that
only
three
succeeded:
two
to
cover
to
complete
the
tasks
and
I'm
curious.
E
B
Definitely
the
main
problem
was
the
staging.
If
you
look
at
our
web
IDE
right
now,
the
way
you
staged
changes
is
first,
everything
is
unstaged,
so
you
have
to
actively
stage
something.
But
if
you
go
into
the
flow
there's
a
couple
of
different
ways,
you
stage
it
either
you
can
stage
all
changes
or
if
you
leave
everything
on
stage,
you
can
click
the
stage
and
commit
button
which
leaves
which
stages
also
everything
but
there's
also
individual
stage
buttons
for
each
file.
B
The
two
users
clicked
on
the
individual
stage
button
and
expected
everything
to
get
staged,
but
it
was
only
the
one
file,
so
they
only
committed
the
one
file
created.
The
merge
request
got
out
of
the
web.
Id
didn't
notice,
the
other
changed
got
lost
because
they
didn't
commit
the
file
and
now
had
a
situation
where
they
actually
didn't
even
see
that
they
didn't
complete
the
task.
They
thought
they
had
committed
both
files.
They
had
not.
A
B
B
B
B
You
can
play
around
with
failure
and
get
part
which
isn't
it,
which
is
an
amazing
product.
It's
really
fun
to
play
one
with
it.
You
can
also
look
at
the
actual
vision
issue
where
we
are
talking
about
how
we
want
to
implement
this.
So
if
any
of
you
wants
to
learn
more
about,
this
feel
free
to
go
in
there
comment
or
just
contact
me
directly,
I.