Artículos etiquetados con:móvil
Navegación móvil: el menú está servido

Durante los últimos años, en el campo del diseño y la usabilidad se ha hablado mucho sobre navegación en móvil. Y cuando digo mucho, quiero decir más de lo usual. En este post haremos un repaso de su evolución y trataremos de explicar cuáles son los motivos de este interés tan constante.

 

ANTES DE iPHONE, TODO ERA PC

Parece que no, pero las interfaces digitales en dispositivos cotidianos llevan con nosotros ya unas cuantas décadas. Cleopatra se lleva menos tiempo con los primeros móviles que con las primeras pirámides, así que imagina.

Con el lanzamiento del primer iPhone, allá por 2007, la navegación móvil comienza a desvincularse de la navegación de escritorio. Por entonces, las interfaces en dispositivos digitales lucían más o menos así:

Vista navegación pocket pc

Windows Mobile 5.0, 2005

Los ordenadores más pequeños o pocket PC (recibían un nombre casi literal) tenían el estilo, la cantidad de opciones, y hasta los mismos fallos de diseño que los sistemas operativos de la época.

Después llegaron las Blackberry con sus teclados físicos y su mejora en la tecnología de stylus para pantallas pequeñas. Poco tiempo tardó Apple en presentar su solución para el Smartphone moderno, ese que no necesita teclas ni punteros ya que su interfaz está pensada para los rechonchos dedos humanos.

Fue en este momento cuando se introdujo una de las pocas soluciones que perduran en el tiempo en el diseño de interfaz digital: el Tab Bar.

 

TAB BAR, UN VIEJO CONOCIDO

El Tab Bar organiza toda la información de la app al primer y más básico nivel de navegación de la misma. Aparece fijo en la zona inferior de la aplicación y permite cambiar rápidamente entre diferentes secciones de la misma. Por regla general, siempre mantiene el mismo formato y aspecto en toda la aplicación.

Navegación móvil - Tab bar iphone

Tab Bar. Guías de estilo de iOS 2017

Es una herramienta útil, relativamente elegante y, lo más importante, funciona. A pesar de ello, con el tiempo la Tab Bar empezó a verse cada vez más como un elemento anticuado, de una época pasada. Éramos personas modernas, no podíamos tener las opciones ahí abajo ocupando sitio. ¿Qué somos? ¿Animales? Necesitábamos una solución más elegante, más sutil, más de diseño.

 

¡OH, THE HAMBURGER MENU!

Eran momentos excitantes en la escena del diseño de UI/UX en productos digitales. Todo era posible. Así que arrastramos todas las opciones que nos ensuciaban la pantalla y las pusimos bajo un icono en una esquina. Nacía así el menú hamburguesa, bautizado por Google con el grandilocuente nombre de Nav Icon.

Navegación móvil - Google Material

Guía de Estilo de Material Design. Google, 2017.

El funcionamiento del menú hamburguesa es sencillo: al pulsarlo se despliega un listado en el que aparecen todas las secciones. Se trata del navigation drawer, un cajón (como indica su nombre en inglés) donde podemos guardar y organizar todas las opciones disponibles, y donde podemos situar otros elementos secundarios como enlaces a preferencias, logos de patrocinadores, etc. El resultado es una interfaz limpia donde destaca únicamente el contenido. Es sencillo, dinámico y nos permite extender la aplicación de forma indefinida. También es muy fácil de vender, pero eso es otro tema…

 

NAVIGATION DRAWER: UN CAJÓN ¿DESASTRE?

Con el nacimiento de la metodología de diseño Mobile First (diseñados primero para móviles y ya, si eso, vamos ampliando hasta la vista de escritorio) este patrón de navegación se fue incorporando a la web. La web comenzó a tener esta pinta:

Portal del empleado de Restalia. Proyecto de SDOS, 2016.

Cabeceras con imágenes enormes, completamente limpias, y con el menú hamburguesa siempre en la esquina. Si tu objetivo principal es ese: ¡enhorabuena, vas en buena dirección! No obstante, hay que tener en cuenta que este tipo de navegación penaliza aspectos esenciales de algunas tipologías de aplicaciones y webs, como la transparencia, el engagement y la facilidad de uso por parte del usuario. Al no ser una opción tan evidente, la cantidad de usuarios que cambian entre secciones baja irremediablemente, y la experiencia en general es más pobre. No se invita a navegar.

Luke Wroblewski, uno de los diseñadores más importantes que actualmente trabajan en Google, compartía hacía unos años en su artículo Lo obvio siempre gana las métricas de una de sus aplicaciones, Polar: la cantidad de usuarios que cambiaban entres secciones se reducía drásticamente al pasar de un menú de navegación con pestañas a uno desplegable, similar al menú hamburguesa.

 

También Mike Stern, autodenominado Apple Design Evangelist, argumenta que en una interfaz digital siempre deberías ver claramente de dónde vienes y hacia dónde puedes ir. Los menús laterales no cumplen con esa función, puesto que ocultan toda la información al primer vistazo del usuario. Además, apunta que un menú hamburguesa duplica (como mínimo) el número de acciones a realizar para cambiar de sección.

Como hemos visto, el menú hamburguesa puede ser una opción interesante a nivel estético pero, a nivel funcional y de experiencia de usuario, los tests de usabilidad demuestran serias dificultades:

  • Afecta negativamente al descubrimiento del contenido, tanto en escritorio como en móvil.
  • No da una idea de lo que hay detrás.
  • La dificultad de las tareas aumenta al no mostrar las opciones claramente desde el primer momento.
  • El tiempo en completar tareas se duplica, como mínimo.
  • Los usuarios no están familiarizados con él. Esta conclusión puede variar según el público objetivo de la aplicación o web, pero sí es cierto que no es reconocible en el 100% de los casos: porque no es un estándar,porque no está soportado por todas las plataformas ni todas las herramientas, y porque lleva relativamente poco tiempo con nosotros.

Entonces, ¿debemos desechar por completo el menú hamburguesa en nuestros diseños? No todavía. Existen herramientas, webs o aplicaciones que se benefician de este tipo de navegación. Es el caso de aplicaciones en las que lo que interesa resaltar un contenido, una funcionalidad o mantener el área limpia y despejada en favor de la productividad.

 

PRIORITY+ O LA OPCIÓN SEGURA

Si el Tab Bar nos limita en número de opciones y los efectos negativos del menú hamburguesa desaconsejan su uso, seguro que te estás preguntando ¿cuál es la mejor opción? La respuesta es ninguna de las dos y las dos a la vez. Nace así el patrón de navegación Priority+, la combinación de ambas soluciones: cuando hay demasiados enlaces, mostramos los más recurrentes o interesantes y escondemos el resto. Un ejemplo claro es el de la aplicación como Facebook, donde se han optado por incluir botones de Más opciones dentro de sus barras de navegación.

Estamos ante una muy buena alternativa, pues da prioridad a ciertos contenidos mientras que deja otras opciones menos importantes a la voluntad de descubrir y buscar del usuario. Los datos indican que el 80% de nuestros usuarios utilizará solamente las opciones destacadas, y no echará de menos las demás. Para los que quieran realizar tareas secundarias o más avanzadas, siempre las podrán encontrar bajo el botón Más.

Navegación móvil - Tab bar Priority+

Gluten Detect. Proyecto de SDOS, 2017.

 

DISEÑANDO MÁS ALLÁ DE LAS TENDENCIAS

A simple vista, este último patrón puede parecer la solución definitiva a todos los problemas de navegación. Sin embargo, ninguna opción será la ideal para todos y cada uno de nuestros proyectos. Cada dispositivo y cada tipo de contenido necesita una estructura distinta en función del objetivo del proyecto y del comportamiento que busquemos provocar en el usuario. Cada proyecto requiere un tipo de navegación.

Portal web de la Diputación de Sevilla. Proyecto de SDOS, 2016.

  • En escritorio, es preferiblemente presentar la navegación de forma evidente, mostrando links en la barra superior de la web. A no ser que tu intención sea la de crear un sitio web lo más elegante y limpio posible.
  • En móvil,  lo aconsejable es repensar la navegación, cuanto más mejor.
    • Si se puede, reducir a 4 o 5 links principales, mostrarlos de forma que sean muy visibles y que resulte evidente que tienen una posición alta en la jerarquía de información.
    • Si tenemos más de 5 enlaces, la opción más razonable es ocultar algunos. Para ello podemos hacer uso del patrón de navegación Priority+.
    • Si una sección tiene mucho contenido, se podría implementar una línea de pestañas en la parte superior, de forma que lo filtre o lo pagine, y facilite la lectura.
    • No olvidemos otros tipos de navegación, ni la conveniencia de colocar enlaces de manera frecuente acompañando al contenido. Utilizando de forma inteligente los estados vacíos de ciertas pantallas sencillas o los tutoriales podemos ayudar a la navegación.

Como ves, no se debe tirar a la basura una solución concreta por sistema, sino estudiar cuidadosamente cada proyecto y sus objetivos para finalmente decidir qué tipo de navegación sería la más conveniente.

En diseño UI/UX, lo realmente importante es aplicar las buenas prácticas de usabilidad a cada proyecto, independientemente de la plataforma en la que estemos. Guiar al usuario a través de nuestra app o nuestra web sin interrupciones ni saltos no es fácil, pero si lo conseguimos, haremos que su experiencia sea agradable y, lo que es mejor aún, haremos que repita.

Y tú, ¿qué opinas?


Cómo compilar aplicaciones Android con Jenkins

En tiempos de desarrollo de software mediante metodologías ágiles, Scrum e integración continua, donde todos los miembros de un equipo integran su código frecuentemente y pueden realizar varias subidas al día dependiendo de las tareas a desarrollar, resulta imprescindible el uso de herramientas que permitan conocer en todo momento el estado del producto, las diferentes versiones y el estado en que se encuentra.

Cada vez que se realiza una subida de código al repositorio, se realiza una integración que compila el código fuente y verifica que se ha realizado correctamente, obteniendo un ejecutable de la aplicación. Para este proceso, en SDOS nos hemos decantado por el uso de Jenkins, un software gratuito y Open Source escrito en Java y está basado en el proyecto Hudson.

 

¿POR QUÉ JENKINS?

Este sistema soporta herramientas de control de versiones como SVN o GIT y puede ejecutar proyectos basados en Ant y Maven, Gradle, etc. Además, al ser un proyecto Open Source, es el más utilizado por los desarrolladores, contando con una gran comunidad de desarrollo y soporte.

Pero Jenkins no es sólo una herramienta para el equipo de desarrollo, también sirve al equipo de QA: del mismo modo que posibilita la ejecución de test automáticos o incluso el uso de Sonarqube, justo después de cada compilación permite comprobar la calidad de la subida.

 

¿CÓMO USAR JENKINS CON ANDROID?

En el desarrollo Android, Jenkins puede servirnos para generar un .apk cada vez que realicemos una subida de código al repositorio, guardándola en un servidor FTP donde tendremos un listado de todas las versiones generadas.

En este post os contamos cómo completar todo el proceso. ¡Empezamos!

 

1. CREAR UN PROYECTO EN JENKINS

En primer lugar, creamos un nuevo Job en Jenkins.

Paso 1 para compilar un .apk en Jenkins

A continuación, seleccionamos un nuevo proyecto Freestyle para poder configurarlo según nuestras necesidades. Escribimos un nombre y hacemos clic en OK.

Paso 2 para compilar un .apk en Jenkins

 

2. CONFIGURAR LAS SECCIONES DEL JOB

GENERAL

En esta sección definiremos lo siguiente:

  • Proyect name y description. Es recomendable dar un nombre intuitivo al proyecto y una descripción concreta para saber qué Job estamos ejecutando:

Paso 3 para compilar un .apk en Jenkins

  • Cuándo se descargan los builds antiguos. Es importante definir un número máximo de build a guardar ya que no queremos sobrecargar la máquina ni llenar de ejecuciones nuestro Job. Como recomendación, nos quedaremos con las 10 últimas ejecuciones realizadas. Si por necesidad del proyecto necesitamos que sean más, podría aumentarse el número, pero debería ser sólo en casos puntuales.

Paso 4 para compilar un .apk en Jenkins

  • Parámetros para ejecutar el proyecto. En la parte general también definiremos los parámetros necesarios para ejecutar un Job. Para añadirlos tenemos que hacer clic en This project is parameterized y seleccionar un Choice Parameter. Los parámetros para la compilación de una app de Android serán los siguientes:
    • Type. Por defecto en Android siempre aparecen dos tipos, debug y release, pero pueden añadirse tipos personalizados. En nuestro caso añadiremos: Release, Preproduction y Debug.
    • Flavors. Un flavor define una versión customizada de la aplicación. Esto nos permite definir diferentes personalizaciones de la aplicación dependiendo de la variante que necesitemos. Por ejemplo, podríamos tener un flavor para una demo de la aplicación y otro con la aplicación completa de pago.
    • Git Parameter. Definiremos como parámetro la rama que queremos del repositorio concreto. Tendremos que definir un valor por defecto para las ejecuciones automáticas. Si tenemos muchas ramas en un mismo repositorio, podemos hacer un filtro por nombre de rama como, por ejemplo, .*_rc.* (todas las ramas que incluyen _rc, release candidate).

Paso 5 para compilar un .apk en Jenkins

Paso 6 para compilar un .apk en Jenkins

 

Puedes encontrar más información sobre los parámetros en este enlace.

 

SOURCE CODE MANAGEMENT

En esta sección definiremos el tipo de repositorio que queremos usar, en nuestro caso será Git.

Una vez que seleccionamos la opción de Git tenemos que añadir:

  • URL del repositorio. Dónde está guardado el código del proyecto.
  • Credenciales. Usaremos en usuario git previamente añadido en Jenkins.
  • Branch. Especificaremos la rama específica del proyecto que usaremos. Como ya la hemos elegido una con el parámetro Git Parameter, le pasamos el valor de ese parámetro con $Branch.

Paso 7 para compilar un .apk en Jenkins

 

BUILD TRIGGERS

En esta sección definiremos el tipo de activador que necesitamos para ejecutar el build. Si no añadimos ninguno, sólo se ejecutará cuando nosotros lo forcemos. Desde aquí también podemos:

  • Realizar una ejecución remota desde un script.
  • Realizar la ejecución de forma periódica, por ejemplo cada noche a las 00:00.
  • Realizar una ejecución cuando se produzca un push o un new merge request en el repositorio.

Por ahora lo dejaremos por defecto y lo ejecutaremos manualmente.

 

BUILD ENVIROMENT

En esta sección definiremos dos opciones:

  1. Borrar la carpeta del workspace antes de cada ejecución (para realizar una ejecución limpia).
  2. Añadir el timestamp a los logs para tener más información.

Paso 8 para compilar un .apk en Jenkins

 

BUILD

En la sección del Build añadiremos un Execute shell para ejecutar los siguientes comandos:

Paso 9 para compilar un .apk en Jenkins

  • chmod +x gradlew: da permisos de ejecución al fichero gradlew por si no los tiene (por defecto ya los tiene).
  • ./gradlew: ejecuta el fichero gradlew en la máquina donde está Jenkins que es un Linux (¡cuidado con este fichero!).
  • assemble: es la orden para compilar una aplicación Android.
  • $Flavor: flavour elegido para la ejecución. Ponemos $ para que se sustituya el valor del parámetro por el seleccionado del desplegable flavor en la sección general.
  • $Type: type elegido para la ejecución. Ponemos $ para que se sustituya el valor del parámetro por el seleccionado del desplegable type en la sección general.

 

POST-BUILD ACTIONS

Desde esta sección realizaremos principalmente tres acciones:

  • Guardar el artefacto generado. Guardaremos todos los ficheros .apk generados en la compilación del proyecto. Por defecto lo guardaremos en: **/*.apk

Paso 10 para compilar un .apk en Jenkins

  • Enviaremos el fichero .apk dentro de la carpeta /apks/ a un servidor FTP. En nuestro caso, tenemos un servidor llamado NAS1 en el que guardaremos el apk generado en una carpeta ya creada dentro del servidor.Nota: para configurar la conexión con un servidor FTP debemos ir a Manage Jenkins > Configure Jenkins > Publish over FTP, y añadir los datos correspondientes a nuestro servidor.

Paso 11 para compilar un .apk en Jenkins

  • Enviar correo cada vez que termine un Build utilizando la acción post-build Editable Email Notification. La configuración que tendremos será la siguiente:

Paso 12 para compilar un .apk en Jenkins

 

Puedes copiar el contenido del mensaje por defecto de este HTML:

Default Subject

[JENKINS- ${JOB_NAME} ] Result of Build $BUILD_NUMBER ${JOB_NAME} Project.

Default Content

<html>
 
<p> Hello. </p>
 
<p>This mail is auto-generated as part of the Jenkins execution of the project <b>${JOB_NAME}</b> </p>
 
<h2> BUILD DETAILS: </h2>
 
<p>
       <b>Project Name:</b> ${JOB_NAME} <br>
       <b>Build URL:</b> ${BUILD_URL} <br>
       <b> Build Number: </b> ${BUILD_NUMBER} <br>
       <b>Build Status: </b> ${BUILD_STATUS} <br>
       <b>Type: </b> $Type <br>
       <b>Flavor: </b> $Flavor <br>
       <b>Branch: </b> $Branch <br>
       <b>Download APK: </b> ${BUILD_URL}/lastSuccessfulBuild/artifact/apks/ <br>
       <b>Log: </b> The log file is attached into this e-mail. <br>
       <b>Log URL: </b> ${BUILD_URL}${JOB_NAME}/lastBuild/console <br>
       <b>Changes: </b> ${CHANGES, format="List of changes: <li><ul>[%a] %m </ul><ul> [Date:] %d </ul> <ul> [Revision:] %r </ul></li> <br>"} <br>
</p>
 
<p> Thank you & Regards. </p>
 
</html>

 

Esta template es genérica para cualquier proyecto ya que usa las siguientes variables:

  • ${JOB_NAME}. Nombre del Job en el Jenkins.
  • ${BUILD_URL}. URL exacta del Job.
  • ${BUILD_NUMBER}. Número de Build ejecutado.
  • ${BUILD_STATUS}. Estado en el que ha finalizado el Build.
  • $Type. Tipo seleccionado al ejecutar el Build.
  • $Flavor. Flavor seleccionado al ejecutar el Build.
  • $Branch. Branch seleccionada al ejecutar el Build, si no se ha elegido ninguna aparece el nombre de la branch por defecto definida.
  • ${CHANGES}. Muestra los cambios realizados en el commit que ha activado el Build.
    • %a: autor del commit.
    • %m: mensaje del commit.
    • %d: fecha del commit.
    • %r: número de commit.

 

Esto dará lugar a un email como el que se muestra a continuación. Obtenemos así el .apk generado de forma sencilla.

Paso 13 para compilar un .apk en Jenkins

 

Sin lugar a dudas, en los últimos años Jenkins se ha convertido en una herramienta indispensable en el desarrollo de software ágil ya que, además de automatizar el proceso de producción de artefactos, garantiza la calidad en cada uno de ellos tanto para el cliente como para el propio equipo.


Uso de cookies

Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continúas navegando estas dando tu consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pincha el enlace para obtener más información.

ACEPTAR