►
From YouTube: UX Showcase: Geo Maintenance Mode
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
Hello,
everyone
again
I'm
sunshine
and
today
I'd
like
to
go
through
the
design
of
the
maintenance
mode
for
the
Geo
team
and
in
the
previous
new
actual
case
presentation.
I
have
already
introduced
the
Geo
application
part
which
is
at
the
vial
viable
level,
but
for
today,
I'd
like
to
focus
on
the
disease
recovery,
which
is
at
the
minimal
level.
A
So
what
is
the
recovery
to
understand?
I
need
to
spend
some
times
on
it
to
understand
the
concept,
and
these
terms
just
come
up
so
failover.
Of
course,
this
terminology
just
popped
up
on
the
documentation,
so
I
need
it
to
google
and
ask
the
Wikipedia.
What
does
this
means
and
it
was
actually
a
panic
attack,
so
I
really
needed
to
paint
the
team
and
to
several
times
to
understand
this
concept
and
to
get
to
know
the
context
better
to
deliver
the
design
for
this
so
for
the
better
understanding
what
its
failover.
A
A
So
since
the
geo
already
provides
the
replication
of
data
base
and
some
artifacts
like
repositories
and
wikis,
so
we
want
to
enable
the
failover
feature
with
very
minimal
effort
and
if
users
already
using
geo,
they
can
to
select
a
secondary,
node
and
promoted
to
the
primary
node,
and
they
can
just
start
playing
around
this
plan.
Failover
case.
A
But
I
understand
that,
because
I
already
mentioned
this
presentation,
Titleist
maintenance
mode,
but
I'm-
keep
talking
about
failover
and
disaster
recovery.
So
why
maintenance
mode
here
so
currently
on
the
Geo?
It's
still
the
disaster
recovery
is
sealing
the
minimal
level,
so
user
can
promote
the
secondary
no
to
the
primary
on
the
comment
line
not
on
the
UI
and
also
the
users
can
disable
the
primary
note
on
the
comment
line,
not
on
the
UI.
So
the
current
challenge
is
pretty
critical
that
your
user
cannot
enable
the
maintenance
mode
at
all.
A
So
we
want
to
make
this
process
more
improved
version,
so
our
PM,
fabien
and
I
came
to
this
conclusion.
Like
okay,
let's
make
this
MVC
goal
of
the
maintenance
mode.
We
have
to
think
about
provide
a
better
way
to
block
out
of
non
optimal
users
and
also
we
have
to
provide
a
better
way
to
read
only
mode
on
the
Gila
fqi.
A
A
So,
as
I
already
mentioned,
we
kind
of
come
up
with
the
two
possible
use
cases.
The
first
one
is
about
the
plan
failover,
so
the
user
flow
was
quite
different
between
the
plan.
Failover
case,
and
also
the
normal
administrative
tasks
so
before
the
plan,
failover
consists
that
me
should
schedule
the
failover
and
they
need
to
communicate
within
the
company
by
email.
I.
A
Don't
think
that
you
spawn
in
this
case,
but
they
mentioned
that
they
use
email
and
also
they
need
to
enable
this
maintenance
mode
by
scheduling
exact
starting
date
or
time
like
three
days
later
or
something
like
this.
So
after
the
enabling
this
maintenance
mode,
they
have
to
check
every
note
on
the
Geo
under
the
tio.
It's
all
synced
and
verified
like
a
hundred
percent
healthy,
and
then
they
need
to
move
on
to
select
the
right
secondary
note
to
promote
that.
A
Okay,
now
you
should
be
work
as
the
primary,
not
as
a
secondary,
and
then
they
can
disable
the
maintenance
mode.
Finally,
so
their
secondary
notice.
Now
the
new
primary
but
I
was
wondering
as
a
designer
like
okay,
this
plan
failover
case
like
what
could
be
the
real
use
case.
Well,
the
real
use
case
might
be
applied
to
the
really
big
organizations,
for
example,
if
they
want
to
shut
down
or
maintain
I,
don't
know
some
scheduling,
some
maintenance
for
their
data.
A
Centers
and
they
really
need
to
shut
down
their
data
center,
so
they
wanted
to
try
out
the
plan
failover
before
the
data
center
shut
down,
and
then
they
feel
kind
of
like
satisfied.
Ok,
now
everything
works
pretty
well
and
then
they
are
kind
of
now
ready
to
ready
for
the
real
disaster
recovery
situations,
and
this
was
the
second
use
case
of
administrative
tasks
which
I
mentioned
already
before
the
before
hands.
That
was
pretty
similar,
but
after
process
is
kind
of
different
and
it's
way
more
simpler.
A
Actually,
so
they
need
to
perform
like
regular
administrative
tasks
like
some
troubleshooting
like
bug,
fix
or
some
tasks
running,
or
they
need
to
create
the
chill
version
or
get
like
version.
Then
they
need
to
enable
this
maintenance
mode
and
lock
out
every
no
not
mean
users,
and
then
they
do
their
own
job
and
then
come
back
and
disable
this
maintenance
mode
and
hey
it's
done,
and
now
you
can
just
use
Gila.
A
So
this
was
my
understanding
and
based
upon
this
understanding,
I
started
to
visualize.
This
idea,
of
course,
I
started
with
wire
framing,
which
is
my
favorite
part,
so
put
the
link
here.
So
this
was
very
first
version
of
draft
of
the
maintenance
mode.
I
got
some
notes
on
it,
so
we
started
to
discuss
based
upon
this
schedules
and
then
started
to
think
about
iterations
and
how?
How
can
we
put
the
read-only
mode
if
this
is
possible?
A
A
I
prepare
for
this
weird
look
like
maintenance
mode
page,
so
we
can
use
this
type
of
maintenance
mode
pages
like
you
need
to
contact
your
administrator,
we're
under
the
maintenance
mode,
so
that
no
not
mean
user
cannot
see
the
UI
at
all
and
the
second
iteration
is
including
the
read-only
mode.
So
since
that
me
can
select
that
ok,
if,
if
we're
under
the
maintenance
mode,
they
can
still
see
the
UI,
but
they
cannot
write
anything.
So
this
was
our
second
iterations
and
thanks
to
Mario's
feedback
I
could
improve
this
design
a
lot
better
than
before.
A
A
So
currently
it's
it's
at
the
moment.
It's
kind
of
like
pause
from
my
side,
because
I
am
still
waiting
for
working
progress.
Like
technical
discussion
like
how
can
we
transfer
this
comment,
light
interaction
to
the
UI,
because
they
this
includes
some
of
the
pseudo
like
comment
which
might
be
dangerous,
so
I
think
we
need
to
think
more
and
also
there
could
be
some
dependency
on
thinking
and
very
fact,
verification
of
data
for
the
planned
failover
case,
so
I'm
still
waiting.
A
If
this
discussion
is
almost
done,
then
now
you're
ready
to
plan
for
the
real
actual
implementation.
So
we
can
start
mapping
out
those
technical
scope
for
the
very
first
iteration
and
then,
at
the
same
time,
I
will
start
validating
this
design
concept
with
the
actual
users.
And
if
really
this
at
work
or
no.
B
Have
a
comment:
it's
very
much
for
sharing
this.
What's
really
stood
out
to
me
throughout
is
how
much
you
collaborated
so
broadly
with
your
team
with
p.m.
with
engineering
and
with
the
UX
team,
and
that's
awesome,
that's
exactly
how
we
should
be
working.
So
thank
you
for
sharing
that,
and
especially
on
something
to
the
point
you
kept
making.
That's
so
deeply.
Technical
feedback
from
the
engineering
team
is
just
absolutely
critical,
so
good
work.
Thank
you
very
much.