El pasado 17 de diciembre de 2014 tuvo lugar la sesión técnica de la que os informamos hace días. En ella los participantes tuvieron ocasión de profundizar con Armando Fidalgo sobre el diseño de interfaces en dispositivos móviles.
El diseño de interfaces de usuario de dispositivos móviles es todo un reto para los diseñadores de interfaz e interacción. Se deben tener en cuenta ciertas características relacionadas con el tamaño de los dispositivos en sí, con los estilos de interacción propios, y el contexto de uso entre otras. Conocer estas características es imprescindible para que la experiencia del usuario al interactuar con estos dispositivos sea positiva. Armando Fidalgo nos lo explicará en esta conferencia.
Armando es diseñador de interacción y experiencia de usuario, y consultor de usabilidad. Su experiencia se remonta al año 2000, y durante 10 años ha sido líder del equipo de diseño de interacción y experiencia de usuario de la reconocida empresa Usolab. Actualmente desempeña su profesión como profesional autónomo en el Reino Unido.
35. Luke
Wroblewski
35
• Diseñar para multidispositivos!
• Favorecer el continuum de pantallas!
• Optimizar para interacción táctil!
• Permitir el cursor & teclado!
45. Cobertura
• Conec>vidad
limitada/intermitente
Cobertura Vodafone
2G 3G
45
• Descargar sólo lo necesario:
focalizarse en lo que solicita el
usuario!
• Evitar descargar elementos o
imágenes meramente decorativas!
• Optimizar el peso de los archivos !
Vodafone.
Marzo
2014
47. “Unlike
the
sta>c
and
predictable
PC
context,
the
mobile
context
is
a
lot
like
life.
It’s
unpredictable,
ambiguous
.
.
.
it’s
everywhere”.
Rachel
Hinman
47
49. § En
movimiento
§ Suscep>bles
a
distracciones
e
interrupciones
§ Disponibles
49
Alexis
Polegato
50. § En
movimiento
§ Suscep>bles
a
distracciones
e
interrupciones
§ Disponibles
§ Sociables
50
Alexis
Polegato
• Ofrecer claridad y foco!
• Focalizarse en el contenido sobre la
navegación!
• Focalizarse en las tareas principales
(1 por pantalla)!
• Conocer realmente lo más
importante (conocer el negocio y a
tus usuarios)!
• Autoguardar!
• Multitarea!
• Facilitar retomar la tarea (en el
mismo dispositivo, en otro...)!
66. Aproximaciones
disponibles
• Aplicaciones
na>vas
• Aplicaciones
híbridas
• Si>os
web
móviles
/
aplicaciones
web
66
• Chris>an
Karasiewicz
67. Aplicaciones
naAvas
• Se
descargan
(desde
el
store)
y
residen
en
el
disposi>vo.
• Son
específicas
de
la
plataforma
y
sistema
opera>vo
(ej:
iOS
o
Android)
• Construidas
con
el
lenguaje
de
la
plataforma
SDK
• Tienen
acceso
y
usan
los
sensores
del
disposi>vo
(GPS,
acelerómetro,
cámara,
etc.)
y
a
los
componentes
del
SO,
como
los
elementos
UI
(botones,
sliders,
pestañas
y
otros
controles),
patrones
de
interacción
(gestos,
transiciones)
y
caracterís>cas
principales
(lista
de
contactos,
logs
de
llamadas).
• Están
integradas
en
el
sistema
de
no>ficaciones
67Chris>an
Karasiewicz
68. SiAos
web
móviles
/
aplicaciones
web
• Corren
en
el
navegador
web
• Escritas
en
HTML
5,
con
hojas
de
es>lo
CSS3
y
javascript
• Las
app
web
parecen
aplicaciones
na>vas
pero
no
se
implementan
como
tal.
Son
efec>vamente
webs.
• Pueden
incorporar
gestos
y
transiciones
(
sólo
los
que
HTML5
soporta)
• No
>enen
la
calidad
de
experiencia
de
las
na>vas
(en
rendimiento,
fluidez,
gestos
naturales,
etc.)
• Ciertas
caracterís>cas
del
SO
na>vo,
como
el
sistema
de
no>ficaciones,
algunos
sensores
y
gestos
avanzados,
no
están
todavía
disponibles
68
Chris>an
Karasiewicz
69. Aplicaciones
híbridas
• Son
una
combinación
de
apps
na>vas
y
web
• Son
esencialmente
aplicaciones
HTML5
empaquetadas
en
contenedores
de
na>vas
• Residen
en
el
disposi>vo
• Se
instalan
desde
el
store
• El
propósito
es
reunir
lo
mejor
de
los
dos
mundos:
– Tener
un
código
único
para
todas
las
plataformas
– Tener
acceso
a
las
capacidades
del
disposi>vo,
como
el
acelerómetro,
GPS,
cámara,
etc.
69Chris>an
Karasiewicz
77. Seguir
las
Guías
de
esAlo
• Especialmente
en
áreas
UX
principales
como
– Navegación
– Controles
básicos
(campos
de
texto,
botones,
pestañas,
desplegables…)
– Acciones
principales
(compar>r…)
– Gestos
(aunque
está
más
abierto)
• Son
“normas”,
recomendaciones
y
consideraciones
generales
de
diseño.
• Son
guías
(en
el
sen>do
de
“dirigir”
o
“encaminar”),
no
mandamientos
77
85. Estructura
85
Layout
popularizado
por
iOS
Barra
de
estado
(de
sistema)
Título
de
pantalla
y
navegación
secundaria
(+
acciones)
Contenido/navegación
principal
Pestañas
de
navegación
86. Estructura
86
Layout
popularizado
por
iOS
Barra
de
estado
(de
sistema)
Título
de
pantalla
y
navegación
secundaria
(+
acciones)
Contenido/navegación
principal
Acciones
87. 1. Barra
de
acciones
principales
2. Control
de
vistas
3. Contenido
principal
4. Barra
de
acciones
“split”
87
92. AcAon
bar
1. Icono
de
aplicación
(con
o
sin
la
affordance
“up”)
2. Control
de
vistas
3. Botones
de
acción
4. “Desbordamiento”
de
acciones
(ac>on
overflow)
92
104. Webs
opAmizadas
para
móvil
• Si>o
web
op>mizado
para
móviles
separado
• Redirigir
los
usuarios
que
visiten
el
si>o
web
al
si>o
web
móvil
• Enlazar
si>o
web
móvil
y
si>o
web
complete
entre
ellos
• Y
mejor…
hacer
una
aplicación.
104
107. Es
importante…
• No
confundir
contexto
con
intención
• No
asumir
más
de
la
cuenta
sobre
el
tamaño
de
la
pantalla
– No
implica
necesitar
menos
información.
– No
implica
necesitar
menos
funcionalidades.
107
108. Contra-‐estrategias
• Enfa>zar,
no
eliminar
• U>lizar
“progressive
enhancement”
(mejora
progresiva)
• U>lizar
técnicas
adapta>vas,
como
responsive
web
design
108
116. Móvil
primero
• Te
fuerza
a
focalizar
y
priorizar
tus
productos
teniendo
en
cuenta
las
restricciones
inherentes
al
diseño
de
móviles
• Te
permite
ofrecer
experiencias
innovadoras
basándote
en
las
nuevas
capacidades
propias
de
los
disposi>vos
móviles
116
123. Planteamiento
Contenido
adapta>vo:
• Es
más
que
“móvil”.
• Contenido
en
un
formato
que
permita
compar>rlo
y
distribuirlo
en
cualquier
plataforma.
• Plataformas
que
controles
(actuales)
o
futuras.
123
125. • El
diseño
se
adapta
al
tamaño
y
orientación
de
la
pantalla
y
al
disposi>vo
que
se
esté
u>lizando.
• El
contenido
es
el
mismo.
125
126. ¿Cómo?
• Grilla
fluida:
columnas
basadas
en
porcentajes
que
cambian
de
forma
flexible
con
el
tamaño
del
disposi>vo
• Imágenes
flexibles:
tamaño
fluido
de
imágenes
basadas
en
porcentaje
• Media
queries:
una
herramienta
de
CSS3
que
detecta
las
caracterís>cas
del
disposi>vo
(tamaño,
resolución
y
otras)
y
lanza
una
hoja
de
es>los
apropiada.
Brad
Frost
126
144. Disfrutar
tocando
Organizar
la
interfaz
para
tocar
Al
alcance
de
la
mano
Al
alcance
de
los
dedos
Interacción
mul>tác>l
Interacción
y
manipulación
directa
Sensación
de
realismo
Feedback
inmediato
Animación
144
161. • Aplicaciones
iOS
– Navegación
en
la
parte
inferior
de
la
pantalla
• Aplicaciones
Android
– Navegación
en
la
parte
superior
de
la
pantalla
• Web
móvil
– Navegación
en
la
parte
inferior
de
la
pantalla
161
Josh
Clark
162. Steven
Hoober
“We
know
that
this
diagram
is
wrong
”
Steven
Hoober
162
168. • Situar
las
acciones
principales
en
el
centro
• Situar
las
acciones
secundarias
arriba
y
abajo
Los
usuarios
prefieren
tocar
el
centro
de
la
pantalla
168
169.
Diseñar
en
función
de
cómo
sos>enen
el
disposi>vo
los
usuarios
169
184.
Al
alcance
del
disposiAvo
periférico
de
introducción
de
datos
en
el
sistema
de
los
dedos
184
185. Yema/pulpejo:
10-‐14
mm
Punta:
8-‐10
mm
Adecuación
de
los
elementos
de
la
interfaz
al
tamaño
de
los
dedos
185
186. Tamaño
del
objeAvo
7
mm
Aceptable
7
mm
ÓpAmo
por
precisión
9
mm
9
mm
§ Para
cerrar,
eliminar
o
acciones
graves
o
importantes
5
mm
5
mm
Mínimo
para
tamaños
pequeños
§ Si
se
necesita
apilar
gran
can>dad
de
elementos
+10
10
7
186
187.
El
tamaño
del
obje>vo
influye
en
la
tasa
de
errores
Microso}
187
188. Tocar
es
impreciso
• Los
obje>vos
tác>les
deben
ser
lo
más
grandes
posible
• Tap
el
contenedor
entero
• Diseñar
con
listas
y
cajas
grandes
188
189. Espacio
en
blanco
entre
objeAvos
2
mm
2
mm
(al
menos)
de
separación
visual
reduce
errores
y
la
percepción
de
dificultad.
189
190. Zona
pulsable
La
zona
pulsable
debe
ser
igual
o
mayor
al
tamaño
real
(visual)
del
botón.
190
191. El
espacio
muerto
reduce
el
peligro
de
pulsar
otro
botón
por
equivocación.
Espacio
muerto
191
202. Para
definir
gestos
en
una
aplicación:
1. Asegurar
que
el
acceso
a
contenidos
y
funcionalidades
principales
u>liza
gestos
básicos.
2. Añadir
gestos
más
complejos
como
atajos
a
las
funcionalidades
más
usadas.
202
213. Chrome
is
the
visual
design
elements
that
give
users
informa>on
about
or
commands
to
operate
on
the
screen´s
content
(as
opposed
to
being
part
of
the
content).
These
design
elements
are
provided
by
the
underlying
system
and
sorrounds
the
user´s
data
J.Nielsen&R.Budiu
“
213
221. When
appropriate,
add
a
realis>c,
physical
dimension
to
your
applica>on.
O}en,
the
more
true
to
life
your
applica>on
looks
and
behaves,
the
easier
it
is
for
people
to
understand
how
it
works
and
the
more
they
enjoy
using
it
iOS
Human
Interface
Guidelines
”
“
221
222. Feedback:
respuesta
inmediata
al
toque
del
usuario
Manipulación
directa
del
contenido,
en
lugar
de
uso
de
controles
Simular
las
leyes
†sicas
(inercia,
resistencia…)
en
los
objetos
Toques
de
realismo
U>lizar
metáforas
del
mundo
real
222
244. Mejora
la
orientación
Las
transiciones
visuales
mejoran
la
comprensión
de
lo
que
ha
pasado
Muestra
cambios
de
estado
o
situación
Muestra
relaciones
entre
elementos
244
246. La percepción periférica del movimiento es eficiente
Dirige
la
atención
del
usuario
Puede ayudar en los cambios de elementos
pequeños o fuera del centro de la pantalla
246
249. Las
transiciones
suaves
añaden
realismo
Ofrece
con>nuidad
y
man>ene
el
flujo
Crea
consistencia
y
con>nuidad
Las
transiciones
deben
ser
suaves
y
su>les
para
no
llamar
la
atención
hacia
sí
mismas
249
252. Reducir
el
cambio
de
pantallas
puede
mantener
el
flujo
Ofrece
con>nuidad
y
man>ene
el
flujo
De
pantallas
discretas
a
movimiento
con>nuo
Abrir,
cerrar
y
refrescar
paneles
con
gestos
Abrir
el
contenido
y
medias
en
la
página
252
272. 272
Luke
Wroblewski
Aportar
valor
inmediatamente
In
the
new
app,
we
present
relevant
content
up-‐front
and
instantly
no>fy
users
of
new
invita>ons
and
messages.
In
other
words,
we
remove
the
fric>on
of
a
dashboard
and
provide
immediate
value
on
app
launch
282. 282
Acciones
principales
Contenido
principal
Navegación
Contenido
secundario
Luke
Wroblewski
283. Controlar la complejidad mostrando la
información necesaria en cada momento.
Presentación
progresiva
283
284. La
revelación
progresiva
difiere
las
caracterís>cas
avanzadas
o
rara
vez
u>lizadas
a
una
pantalla
secundaria,
haciendo
las
aplicaciones
más
fáciles
de
aprender
y
menos
propensas
a
errores.
Jakob Nielsen
“
”
284
301. 301
La regla general es limitar
el uso de formularios en
el contexto móvil
Brian
Flig
“
Evitar
introducir
inputs
al
usuario
Evitar
introducir
inputs
al
usuario
…
cuando
sea
posible
305. Barron
Cuadrro
305
En
web
no
es
muy
adecuado.
Menos
en
móvil.
No
solicitar
datos
306. Barron
Cuadrro
306
No
solicitar
datos…
a
no
ser
que
sean
absolutamente
necesarios
Solicitar
el
mínimo
de
información
necesaria
para
la
tarea
307.
Rellenar
por
defecto
el
formulario
con
los
datos
personales
conocidos
Usar
el
autocompletado
y
sugerencias
Guardar
y
u>lizar
la
historia
de
uso
307
Mostrar
seleccionado
por
defecto
los
datos
per>nentes