viernes, 16 de junio de 2017

Programación Visual con Node-Red: Conectando el Internet de las Cosas con Facilidad

A través de la programación, hacemos que las máquinas imiten un comportamiento complejo siguiendo secuencias de instrucciones simples. Utilizar lenguajes de programación textual como Asambly, C, Python y JavaScript, es una de las formas principales de hacerlo. Los diseñadores de estos lenguajes de programación han pasado horas y horas tratando de hacer que la experiencia de los programas de escritura sean lo más fácil posible a través de una sintaxis expresiva, fuertes construcciones de programación y cadenas de herramientas poderosas. Sin embargo, todos estos lenguajes de programación comparten un rasgo común: el código fuente textual.
Escribir programas en texto funciona y en la mayoría de los casos funciona bien. Sin embargo, la capacidad de expresar programas visualmente es a menudo deseable. Ser capaz de diseñar el flujo de información a través de diversos componentes de un sistema más grande es normalmente todo lo que se necesita. Las herramientas visuales de programación también son indulgentes con cualquier persona que sea nuevo en la programación y que les es difícil manejar diversos conceptos como las variables, indicadores, señales, alcances, y así sucesivamente.
Connect Hardware Devices With APIs Using Node-RED
Node-RED es una herramienta de programación visual. Muestra visualmente las relaciones y funciones, y permite al usuario programar sin tener que escribir una lengua. Node-RED es un editor de flujo basado en el navegador donde se puede añadir o eliminar nodos y conectarlos entre sí con el fin de hacer que se comuniquen entre ellos.
En Node-RED, cada nodo es uno de los siguientes dos tipos: un nodo de inyección o un nodo de función. Los nodos de inyección producen un mensaje sin necesidad de entrada y lanzan el mensaje al siguiente nodo conectado a éste. Los nodos de función, por el contrario, tienen una entrada y realizan algún trabajo en él. Con una gran cantidad de estos nodos para elegir, Node-Red hace que el conectar los dispositivos de hardware, APIs y servicios en línea sea más fácil que nunca.

Primeros Pasos con el Node-Red

Node-Red se basa en Node.js. Para instalar el Node-Red, necesitas tener tanto Node.js instalado como NPM. Con NPM, es muy fácil instalar Node-Red: npm install -g node-red
El editor de flujo de Node-Red es una aplicación basada en navegadores web. Para poder utilizarlo, ejecuta Node-Red:
npm install -g node-red
Node-RED’s flow editor is a web browser based application. To be able to use it, run Node-RED:
node-red
&hellip y vaya a http: // localhost: 1880.

¡Hola Mundo!

¿Qué tutorial de programación para principiantes está completo sin aprender a decir “Hola, mundo”? Vamos a empezar por probar exactamente eso:
  1. Arrastra y suelta un nodo de inyección en el editor de flujo. Después, haz doble clic y fija la carga útil como cadena y escribe “Hola mundo”.
  2. Arrastra y suelta un nodo de depuración, de la misma manera como lo hiciste con la inyección.
  3. Conéctalos.
  4. Haz clic en el botón “Deploy” en la esquina derecha.
  5. Haz clic en el botón azul justo a la izquierda del nodo de inyección.
Inténtalo. Verás algo como esto:

Sólo JavaScript

Con Node-Red, no te limites con simples nodos y funcionalidades. Como Node-Red está construido sobre Node.js, todo está impulsado por JavaScript. Los nodos son, de hecho, Node.js módulos. Se pueden encontrar en http://flows.nodered.org/, entonces para añadirlos a tu panel de la izquierda se pueden simplemente “instalar con NPM “. De hecho, puedes desarrollar tu propio flujo y subirlos al repositorio de flujo. Las aplicaciones pueden ser tan complejas como desees ya que puedes escribir JavaScript en los nodos de función dentro del editor de código que proporciona Node-Red.
Ya que la plataforma se basa en Node.js, ésta se aprovecha del mismo modelo orientado a eventos y sin bloqueos. Así que una aplicación construida en Node-Red puede ejecutarse en hardware de bajo costo como el Raspberry Pi, así como en la nube.

Ahora Nos Vamos a Meter en las Grandes Ligas: Es hora de Automatizar el Hogar

Para demostrar cómo Node-Red se ajusta en el ámbito del Internet de las Cosas, vamos a construir una aplicación para cambiar el color de una bombilla inteligente. No todo el mundo puede tener el mismo sistema de iluminación inteligente a su disposición, pero no hay nada de qué preocuparse, ya que se puede encontrar el módulo Node-Red apropiado desde el repositorio oficial de flujo. Sin embargo, para hacer las cosas aún más fácil vamos por algo más inteligente.
Déjmae presentarte a Netbeast. Es una plataforma de código abierto para el desarrollo de aplicaciones para los aparatos y dispositivos del Internet de las cosas sin tener que preocuparse por los detalles como los protocolos inalámbricos, compatibilidad de marca, o tener que saber cómo tratar con cada API específica que existe. ¡Nos permite utilizar los dispositivos virtuales que actúan como los de verdad! Así que incluso si no tienes una bombilla inteligente, tienes una virtual disponible.
Podemos instalar el paquete de NPM de Netbeast para Node-Red a nivel mundial así:
npm install -g node-red-contrib-netbeast
El netbeast-red node representará el panel de control Netbeast, lo que traducirá sus primitivas API para todos los dispositivos inteligentes que tienes en casa. ¡Afortunadamente, también está disponible como un módulo!
Inicia Netbeast:
npm install -g netbeast-cli
netbeast start
Esto hará que el panel esté disponible en el puerto 8000 y SSL en 8443. A continuación, abre el navegador a http://localhost:8000 y navega a Explore. Ahí podemos encontrar muchas aplicaciones y plugins. Busca las marcas de tus bombillas inteligente (Philips Hue, LIFX, Wemo) o si no tienes una, intenta descargar el plugin de la bombilla. ¡Comprueba que los plugins del panel contienen uno de estos!
La insignia amarilla indica que los plugins se están ejecutando, pero no pueden encontrar ningún dispositivo. Haz clic en el plugin de la bombilla para crear una bombilla virtual. Cualquier otro dispositivo que se descubra debe aparecer en la red.
Con todo en su lugar, volvamos al trabajo. Haremos un flujo simple:
  1. Arrastra y suelta un nodo de inyección.
  2. Arrastra y suelta el nodo Netbeast.
  3. Arrastra y suelta un nodo de depuración.
  4. Conecta todo como se muestra a continuación:
Ahora vamos a enviar una petición HTTP al panel de control. Al usar la API Netbeast se tendrá que enviar a través del nodo de inyección un JSON que contiene los valores que queremos que se activen en nuestra bombilla.
¡Presiona el botón para inyectar el color y la energía a todas tus bombillas inteligentes!
Cada tema representa un tipo diferente de dispositivo. Así que hay temas no solo para las luces, sino también para la música, calefacción, y el vídeo; así como sensores para la humedad, la presencia, la temperatura, y la lista continúa. Puedes encontrar en tu documentación una lista de temas y su estructura recomendada para ser traducido a todo tipo de dispositivos. Este motor de la IO es novato, pero potente. Un código abierto que permite a los desarrolladores reutilizar la información para crear escenarios realmente conectados, siendo de este modo inteligente.

Ahora Adentrémonos Más

A continuación, vamos a crear un segundo flujo usando otro plugin, un detector de ruido ambiental para utilizarlo como un iniciador para cambiar el color de la bombilla como un semáforo de ruido. En este tutorial vamos a utilizar uno virtual, así que no hay necesidad de comprar un nuevo hardware. Vamos a empezar haciendo clic en el botón “más” en el editor de Node-Red.
Ve de nuevo al Panel http://localhost:8000/explore a la sección Explorar y busca Volume-Plugin. Se trata de una aplicación web muy rudimentaria que se aprovecha de getUserMedia() dentro del navegador para capturar la información multimedia desde una simple aplicación HTML. Por lo tanto, es probable que sólo funcione en los navegadores modernos.
Haz clic en él para abrir, al igual que con la bombilla virtual. En él se solicita permiso para grabar desde el micrófono. A continuación, enviará los mensajes al intermediario MQTT de Netbeast, que será compartido a través de todo el panel de control, y así podremos suscribirnos. Para lograr esto sólo necesitaremos arrastrar y soltar un nodo de netbeast-trigger en el editor node red. A continuación, vamos a insertar una función entre el trigger y el nodo Netbeast, para decidir cuando está demasiado alto y cuando no. Además, deberíamos utilizar algunos nodos de depuración para comprobar si todo está bien. El esquema ahora se verá algo como esto:
Ahora, vamos a introducir algún código en el nodo de función tooLoud. Sí, sé que prometí que podrías programar sin necesidad de codificar, ¡pero ya he demostrado que puedes! Y se puede tratar de combinar los diferentes elementos disponibles u otros nodos del registro para llevar a cabo lo siguiente.
var volume = msg.payload.volume

node.log(volume)

if (volume < 50) {
    return { topic: 'lights', payload: { power: 1, color: '#00CC00'}}
} else if (volume < 75) {
    return { topic: 'lights', payload: { power: 1, color: '#CCCC00'}}
} else {
    return { topic: 'lights', payload: { power: 1, color: '#FF0000'}}
}
Este fragmento de código bastante simple está regresando una de las tres cargas útiles para el siguiente nodo con un código de color específico, dependiendo del nivel de volumen reportado por el nodo anterior.
¡Ahora estamos listos para continuar! Vamos a presionar el botón Deploy de nuevo y armemos un griterío. ¡Veamos cómo cambia la bombilla de un color a otro de inmediato!
Ya que el micrófono y el navegador web que estás utilizando podrían ser diferentes, no dudes en ajustar los valores de la función y umbrales, y también juega con los valores de color para ver cómo cambia tus bombillas.

Crea tus Propios Plugins

Esta bombilla en CSS puro se inspiró en éste cssdeck.
Como habrás notado, la bombilla virtual anterior es muy rudimentaria, por lo que es posible que desees modificarla. O mejor aún, puedes crear tus propios controladores para un hogar inteligente. Así que vamos a pasar por el proceso de crear un plugin virtual para Netbeast, lo que te permitirá crear tus propios controles para dispositivos inteligentes.
Puedes utilizar el paquete netbeast-cli para generar como por arte de magia algunos códigos. Mediante la ejecución de netbeast create myplugin --plugin tendríamos un proyecto básico como el siguiente:
myplugin
├── README.md
├── index.js
├── package.json
└── test.js

Frontend

Ahora, vamos a empezar a mimetizar la bombilla con un frontend. Los controladores de dispositivos por lo general no van a tener uno, así que el comando de andamio no incluye una carpeta pública todavía. Vamos a crear un directorio public dentro del proyecto y colocamos allí los siguientes archivos HTML, CSS y JS.

index.html

<head>
  <title>Netbeast Bulb Plugin</title>
  <link rel="stylesheet" href="bulb.css" media="screen" charset="utf-8">
</head>

<body>
  <div class="top-decoration"></div>
  <div id="plugin front-end">
  </div>
  <div class="bulb-container small">
    <div class="bulb light">
      <div id="bulb">
        <div class="bulb top"></div>
        <div class="bulb middle-1"></div>
        <div class="bulb middle-2"></div>
        <div class="bulb middle-3"></div>
        <div class="bulb bottom"></div>
      </div>
      <div id="base">
        <div class="screw-top"></div>
        <div class="screw a"></div>
        <div class="screw b"></div>
        <div class="screw a"></div>
        <div class="screw b"></div>
        <div class="screw a"></div>
        <div class="screw b"></div>
        <div class="screw c"></div>
        <div class="screw d"></div>
      </div>
    </div>
  </div>
    <div class="code-container">
      <pre><i class="txt-red">beast</i>(<i class="txt-green">'lights'</i>).<i class="txt-blue">set</i>({
  <i class="txt-green">color</i>: <i class="txt-green">"<input id="color" type="text" class="color" name="color" value="00fea5">"</i>,
  <i class="txt-green">power</i>: <i class="txt-green">"<input id="power" type="text" class="power" name="power" value="on">"</i>
})</pre>
    <button id="run-btn">
      RUN
    </button>
  </div><!-- wrapper -->

  <!-- declares bulb features and methods -->
  <script type="text/javascript" src="bulb.js"></script>
  <!-- real time comms library -->
  <script type="text/javascript" src="socketio.js"></script>
  <!-- simulates hardware communication -->
  <script type="text/javascript" src="hw-api.js"></script>
</body>

bulb.css

section {
  float: left;
  padding: 20px 50px 20px 50px;
}

.bulb-light {
  border: 0;
  background: transparent;
  margin: 0 auto !important;
  padding: 0 !important;
  display: block;
  z-index: 1;
}

#bulb { opacity: 1; z-index: 3; display: block;}

.bulb.top {
  border: 0;
  width: 300px;
  height: 300px;
  margin: 0 auto;
  padding: 0;
  border-radius: 999px;
  background: #E7E7E7;
}

.bulb.middle-1 {
  margin: -75px auto 0 auto;
  width: 190px;
  border-left: 35px solid transparent;
  border-right: 35px solid transparent;
  border-top: 55px solid #E7E7E7;
}

.bulb.middle-2 {
  margin: -22px auto 0 auto;
  width: 178px;
  border-left: 19px solid transparent;
  border-right: 19px solid transparent;
  border-top: 50px solid #E7E7E7;
}

.bulb.middle-3 {
  margin: -20px auto 0 auto;
  width: 182px;
  border-left: 5px solid transparent;
  border-right: 5px solid transparent;
  border-top: 30px solid #E7E7E7;
}

.bulb.bottom {
  width: 184px;
  height: 65px;
  margin: -8px auto 0 auto;
  padding: 0;
  border-radius: 0 0 999px 999px;
  background: #E7E7E7;
}

#base { position:relative; z-index: 2; }

.screw {
  transform: rotate(-3deg);
  -ms-transform: rotate(-3deg);
  -webkit-transform: rotate(-3deg);
  padding: 0;
}

.screw-top {
  margin: -18px auto -4px auto;
  padding: 0;
  width: 132px;
  height: 0;
  border-left: 15px solid transparent;
  border-right: 15px solid transparent;
  border-top: 21px solid #D3D3D3;
  border-radius: 999px;
}

.screw.a {
  background: #DDD;
  width: 150px;
  height: 15px;
  border-radius: 999px;
  margin: -1px auto 0px;
}

.screw.b {
  background: #D9D9D9;
  width: 135px;
  height: 15px;
  margin: -1px auto 0px;
}

.screw.c {
  margin: -1px auto 0px;
  width: 78px;
  height: 0;
  border-left: 30px solid transparent;
  border-right: 30px solid transparent;
  border-top: 20px solid #DDD;
  border-radius: 8px;
}

.screw.d {
  margin: 0 auto;
  width: 15px;
  height: 0;
  border-left: 30px solid transparent;
  border-right: 30px solid transparent;
  border-top: 15px solid #444;
}

.on #light {
  -moz-opacity: 1;
  -khtml-opacity: 1;
  opacity: 1;
}

.bulb.top, .bulb.bottom {
  transition: all 0.5s ease-in-out;
}

.bulb.middle-1, .bulb.middle-2, .bulb.middle-3 {
  transition: all 0.5s ease-in-out;
}
Con estos archivos HTML y CSS, ya se debería poder ver una forma de bombilla en tu navegador. ¡Abre el archivo HTML para ver en vivo! ¿Está funcionando? Bien, ahora vamos a darle algunas funciones.

bulb.js

Este archivo imitará el comportamiento de una bombilla con un simple clic de encendido. Al hacer click para apagarla, establecerás un par de funciones que serán utilizadas un poco después para cambiar su color a través de Netbeast.
var color = document.getElementById('color')
var power = document.getElementById('power')
var bulb = document.getElementById('bulb')
var button = document.getElementById('run-btn')
var light = document.getElementById('light')

button.onclick = function toggleBulbState () {
  changeBulbParams({ color: color.value, power: power.value })
}

function setBulbParams (params) {
  if (params.power === 'off') {
    params = { color: 'E7E7E7' }
  }
  console.log('set params', params)

  var bulb_parts = ['.bulb.middle-1', '.bulb.middle-2', '.bulb.middle-3']

  document.querySelector('.bulb.top').style.boxShadow = '0px 0px 98px #' + params.color

  document.querySelector('.bulb.top').style.backgroundColor = params.color
  document.querySelector('.bulb.bottom').style.backgroundColor = params.color
  bulb_parts.forEach(function (className) {
    document.querySelector(className).style.borderTopColor = params.color
  })
}

function changeBulbParams (params) {
  console.log('change params', params)
  /* Overwrite html fields if necessary */
  color.value = params.color || color.value
  power.value = params.power || power.value
  setBulbParams({color: color.value, power: power.value})
}
Luego, todo comenzará a tener sentido: los campos y el botón de ejecución, ¡ahora podrás comenzar a probar los diferentes colores de tu nueva bombilla virtual! Sin embargo, la razón por la que vinimos hasta aquí es para hacer otro dispositivo de nuestro ecosistema del Internet de las Cosas.

hw-api.js

El último de front-end JS realizado por nosotros mismos, simula una conexión inalámbrica con el servidor, como lo haría un WiFi o bombilla Bluetooth con su mando a distancia, tales como un teléfono, un servidor o un hub. ¡Es la interfaz que el código plugin utilizará para controlarlo!
var socket = io.connect()

socket.on('connect', function () { console.log('ws:// bulb is online') })
socket.on('disconnect', function () { console.log('ws:// connection with bulb lost') })

socket.on('set', function (params) {
   changeBulbParams(params) // uses functions from bulb.js!
})

socket.on('get', function () {
  const params = { power: power.value, color: color.value }
  socket.emit('params', params)
})
Por último, necesitamos que la biblioteca WebSocket sea incluida en nuestro HTML para que la interfaz esté lista. Puedes copiar el código fuente de https://raw.githubusercontent.com/netbeast/bulb-plugin/master/public/socketio.js y pegarlo en un archivo llamado socketio.js. Desde un terminal con curl o wget, lo puedes hacer así de simple:
curl https://raw.githubusercontent.com/netbeast/bulb-plugin/master/public/socketio.js  > public/socketio.js
Tendríamos ahora una estructura de archivos que se ve así:
myplugin
├── README.md
├── index.js
├── package.json
├── public
│   ├── bulb.css
│   ├── bulb.js
│   ├── hw-api.js
│   ├── index.html
│   └── socketio.js
└── test.js

Backend

Ahora vamos a implementar la interfaz con el dispositivo y registrarlo en el motor Netbeast. Éste escuchará los websockets para detectar si alguna bombilla se ha instalado en la red, y luego hará un POST a la API del panel de control para que los nuevos recursos estén disponibles.
Por eso, vamos a echar un vistazo a los archivos que generamos antes:

package.json

Este archivo contiene todas las dependencias y la información necesaria para ejecutar tu aplicación. Netbeast utiliza el habitual package.json también para recuperar cierta información, como el nombre o el tipo. ¡Es importante especificar que este paquete es un plugin!
{
  "name": "myplugin",
  "version": "0.0.0",
  "description": "Netbeast plugin for... <your description>",
  "main": "index.js",
  "netbeast": {
    "bootOnLoad": true,
    "type": "plugin"
  },
  "dependencies": {
    "bluebird": "^3.3.5",
    "body-parser": "^1.15.0",
    "express": "^4.13.4",
    "minimist": "^1.2.0",
    "mocha": "^2.3.2",
    "morgan": "^1.6.1",
    "netbeast": "^1.0.6",
    "socket.io": "^1.4.5",
    "superagent": "^1.8.3"
  },
  "devDependencies": {},
  "scripts": {
    "test": "node test.js",
    "start": "node index.js"
  },
  "repository": {
    "type": "git",
    "url": "GITHUB_REPOSITORY"
  },
  "keywords": [
    "iot",
    "netbeast",
    "plugin"
  ],
  "author": "YOUR_EMAIL",
  "license": "GPL 3",
  "bugs": {
    "url": "ISSUES_CHANNEL"
  },
  "homepage": "HOMEPAGE"
}

index.js

¡Éste es el código que se trae desde el panel de control de Netbeast para lanzar el plugin! Éste tendrá que aceptar el puerto a través de argumentos de línea de comando para saber dónde aceptar peticiones entrantes. Se lanzará como si escribiéramos node myplugin.js --port <a free port number>. ¡Recuerda tomar en cuenta el hashbang al principio! #!/usr/bin/env node.
#!/usr/bin/env node

var io = require('socket.io')()
var express = require('express')
var bodyParser = require('body-parser')

var app = express()

// Netbeast apps need to accept the port to be launched by parameters
var argv = require('minimist')(process.argv.slice(2))

app.use(express.static('public')) // will serve our app in an HTTP server
app.use(bodyParser.json()) // will parse JSON API calls
app.use('/api', require('./plugin')(io)) 

var server = app.listen(argv.port || 31416, function () {
  console.log('Bulb plugin listening at http://%s:%s', server.address().address,
  server.address().port)
})

// we need websockets to push updates to browser view
io.listen(server)
Como se puede ver nos faltaba un archivo por iniciar, el que realmente implementa los controladores socket.io. ¡Nada sofisticado!

plugin.js

var express = require('express')
var netbeast = require('netbeast')

var router = express.Router()
var bulbParams // auxiliar variable, nasty way to transmit changes, but works

module.exports = function (io) {
  io = io
  
  // Create resource that works on lights topic and listens on /api route
  netbeast('lights').create({ app: 'myplugin', hook: '/api' })

  io.on('connection', function () { 
   console.log('ws:// bulb has connected to plugin') 
  })

  io.on('disconnection', function () { 
   console.log('ws:// bulb has disconnected from plugin') 
  })

  io.on('connect_failure', function (err) { console.trace(err) })

  router.post('/', function (req, res) {
    io.emit('set', {
      power: req.body.power,
      color: req.body.color,
    })
    res.status(200).json(req.body)
  })

  router.get('/', function (req, res) {
    io.emit('get')
    var timerReference = setTimeout(function () {
      if (bulbParams) {
        res.json(bulbParams)
      } else {
        res.status(200).json({ error: 'No bulb available' })
      }
    }, 3000)
  })

  return router
}

Inicia tu Aplicación

Ahora es el momento de probar la aplicación. Puedes empaquetarlo todo en un formato tar.gz y luego subir la aplicación a tu panel de control en la sección de arrastrar y soltar http://localhost:8000/install.
beast package # Compresses your app when ran in myplugin dir
¡Voilà! Ahora puedes ir a tus plugins y probarlo. Ve a la sección de red (http://localhost:8000/devices) para ver su funcionamiento y cambiar su color a partir de ahí.
Si algo sale mal o piensas que podrías haber olvidado un detalle, trata de ejecutar localmente con el nodo node index.js, y tal vez será más fácil de depurar que dentro del registro netbeast start.

Publicar su trabajo

Si deseas que la aplicación aparezca en el panel de control de la sección Explore de Netbeast, debes crear un repositorio en GitHub con la aplicación o plug-in de Netbeast, ambos incluidos en la descripción y README.md.
Para encontrar las aplicaciones que hacemos, usa la API de búsqueda de GitHub. Vemos los mismos resultados que aparecen cuando se realiza una solicitud GET a:https://api.github.com/search/repositories?q=netbeast+language:javascript
¡Sabrás que se mostrará tu aplicación, si parece hay!

¿Qué sigue?

Ambos proyectos son de open source y realmente han involucrado a las comunidades. Si deseas comenzar a crear tus propios flujos o nodos al Node-Red, echa un vistazo a su documentación oficial. Sigue los pasos descritos allí y podrás publicar tu propio nodo o flujo en poco tiempo.
Por otro lado, si quieres entrar en el interior Netbeast, puedes seguir su documentación también o echar un vistazo al repositorio del panel. Al usar la API Netbeast, no tienes que centrarte en los dispositivos individuales, marcas o tecnologías, así que dale una oportunidad. Puedes aprender más sobre esto en NetBeast.co y unirte a su Slack channel para discutir Node-RED, IoT o Node.js.
Si deseas instalar esto en una Raspberry Pi, Beagle Bone o servidor antiguo, lo convertirías en un Smart Hub fácil de hackear, ¡sin código! Hay instaladores ya hechos para ellos en ambos sitios.
Feliz hacking.
Artículo original en Toptal.

viernes, 9 de junio de 2017

Procesos De Trabajo De Diseño Para Desarrolladores: Entregando Mejor UX/UI En Tiempo Y Forma

Nota del Editor: Lubos Volkov es un diseñador experimentado quien ha trabajado de forma remota con una gran cantidad de desarrolladores a lo largo de su carrera. Como el _product designer de Toptal, Lubos interactúa día a día con miembros del equipo de una variedad de departamentos, incluyendo desarrollo, comunidad, y contenido. Él es un talentoso diseñador cuyas habilidades de comunicación contribuyen a su éxito. En este tutorial, Lubos comparte sus experiencias y formas de optimizar los flujos de trabajo entre diseñador y desarollador, UI y UX que llevarán a productos de óptima calidad a ser entregados incluso antes de la fecha límite._
Trabajar con un gran diseñador o equipo de diseño puede ser un recurso invaluable para cualquier equipo. Con canales de comunicación claros y cooperación que fluya libremente, el diseñador debería darte todo lo que necesitas para acelerar el proceso de construcción y limitar preguntas y confusiones lo más posible.
¿Qué puedes hacer tú, el desarrollador UX, para asegurarte de que el producto que has construído sea entregado en tiempo y forma sin sacrificar la calidad de la interfaz y experiencia de usuario?
Llama a tu diseñador; es tiempo de reestructurar el proceso de trabajo del diseño UI.
Mi respuesta: Deja que tus diseñadores se involucren desde el primer día, y mantenlos involucrados a través de todo el proceso de desarrollo UI/UX. Asegúrate de establecer líneas de comunicación claras y que haya un proceso de mensajes consistente entre desarrolladores y diseñadores.

¿Tienes Todo Lo Que Necesitas?

La peor cosa que puede ocurrir durante la implementación de cualquier UI es falta de comunicación entre diseñador y desarrollador (a menos que sean la misma persona). Algunos diseñadores pensarán que su trabajo está listo una vez que envíen el PSD, pero en realidad, ¡eso está mal! Siempre debes tener un proceso de comunicación que dure a través del envío de los PSDs.
Proyectos donde el diseñador sólo envía los archivos de diseño, y el desarrollador sólo los implementa, son proyectos que simplemente fallan.
En muchos casos, tomará tiempo antes de que los diseñadores vean algo de UX/UI final implementado. Para su sorpresa, el build es muchas veces completamente diferente de la presentación inicial. (Esto me pasó más de una vez. He enviado los archivos originales con descripciones completas y prototipos de interacción, pero cuando finalmente vi el proyecto unos meses después, tenía una estructura diferente, diferentes colores, y no interacciones en su lugar.)
Algunos diseñadores podrían odiarme por esto, pero este proceso de trabajo de diseño requiere mucho trabajo “extra” de su lado. Sin embargo, crear y enviar información y recursos de forma organizada es mejor para el proyecto y el equipo a gran escala.
Si un desarrollador tiene todo lo que necesita frente a sus ojos, entonces el proceso aumentará su velocidad. Un PSD limpio y organizado no es suficiente.
¿Qué necesitas para que el trabajo se realice efectiva y eficientemente?
Estos son los grandes recursos que un desarrollador debería esperar de un diseñador para implementar diseño UX/UI:
  • Archivo original - El diseñador debería poner todos los elementos de la app en un sólo archivo. Dicho archivo debería contener botones, checkboxes, estilos de header, tipografías, colores, etc. Básicamente, basado en la información de este archivo, el desarrollador debería poder recrear cualquier interfaz desde cero. Es mucho más fácil para un desarrollador exportar cualquier elemento de un PSD sólo que buscar en múltiples archivos.
  • Recursos - Asegúrate de que los desarrolladores tengan todos los recursos necesarios, ya que los archivos originales no deberían ser tocados nuevamente.
  • Interaction prototypes - Los días de “pantallas estáticas” ya no existen. Utilizar interacciones y animaciones inteligentes para suavizar el proceso de UX e implementación del mismo es una práctica muy común hoy en día. Pero, no puedes decir simplemente “esto se deslizará desde la izquierda” a un desarrollador. El diseñador deberá crear el prototipo para esa interacción, y deberá incluir información como velocidad, rapidez, etc., y el diseñador se supone deberá especificar cada uno de estos valores.
  • La convención de los nombres - Requiere una estructura para nombrar a los diferentes archivos y mantenerlos organizados. Hará las cosas más fáciles para ambos a la hora de navegar los archivos. (A nadie le gusta tener cosas escondidas en una carpeta invisible).
  • Recursos HDPI - Vivimos en “tiempos difíciles”, con la gran densidad de las pantallas. Asegúrate de que el diseñador entregue las imágenes en todas las resoluciones requeridas, para que tu aplicación se vea bien en todos lados. Nota: usa cuantos más vectores puedas, te ayudará bastante (svg).
Si hay algo que no encuentres durante la implementación, no tengas miedo; habla con el diseñador y pídeselo. ¡Nunca te saltees ni escatimes nada! Son miembros del mismo equipo, y su trabajo es entregar el producto que mejor sea posible. Si el diseñador falla, tu también lo haces.

Trabajo En Proceso

Utiliza a tus diseñadores durante el proceso de implementación de UI/UX. No los dejes a un lado esperando que ellos simplemente “empujen los píxeles”. Un diseñador ve posibles innovaciones incluso antes de que la implementación comience. Toma ventaja de esto, mantenlos informados. Provéeles con acceso para ver y probar el trabajo en proceso. Estoy seguro de que a nadie le gusta compartir cosas sin terminar, pero es mucho más fácil hacer cambios en el medio del build que hacerlo una vez que se termina. Hacerlo te ahorrará tiempo y prevendrá trabajo innecesario. Una vez que le des al diseñador una chance de probar el proyecto, pídele compilar una lista de problemas y soluciones, y sugerir mejoras.
¿Qué hacer cuando un desarrollador tienen una idea que cambiará el aspecto de una aplicación? Háblalo con el diseñador, y nunca permitas que un desarrollador modifique el diseño sin consultarle al diseñador. Este proceso de trabajo de diseño te ayudará que estés en el camino correcto. Un gran diseñador tiene una razón por cada elemento en la pantalla, y quitar una sola pieza sin entender por qué está ahí, podría arruinar la experiencia de usuario del producto.

Diseño de Gestión del Proyecto UI/UX

Los diseñadores pensarán que los desarrolladores pueden traer a la vida a un diseño en un día, o incluso en una hora. Pero como un gran diseño, un gran desarrollo requiere tiempo y esfuerzo. Mantén a tu diseñador ansioso apenas un poco lejos para dejarle ver al menos el proceso del build. Utilizar un software externo para gestionar un proyecto, para asegurarse de que cada revisión se haya visto, es una gran manera de asegurarte de que no te olvides de nada importante ni ninguna información que se haya hablado en una conversación de Skype o email. Y seamos honestos: algunas veces, cambios y actividades nunca son comunicadas hasta que suceden.
Cualquier solución que utilices, asegúrate de elegir un proceso de trabajo que todo el equipo pueda adoptar y usar con consistencia. En nuestro equipo, intenté proponer Basecamp porque eso es lo que estaba usando, pero nuestros desarrolladores front-end pensaron que tenía características limitadas. De por sí, ya estaban usando otros softwares de gestión de proyecto para llevar cuenta de bugs, progreso, etc., como JIRA, GitHub, e incluso Evernote. Entendí que el proceso de gestionar y llevar cuenta de información y comunicación debería ser lo más simple posible, así que tuve que migrar mi proceso de trabajo de diseño UI a JIRA. Quería asegurarme de que ellos entenderían mi proceso de trabajo y progreso, pero no quería que sintieran que el diseño sería otra cosa más que gestionar.
A continuación, un par de sugerencias para herramientas de gestión de proyecto:
  • Basecamp - Lleva cuenta de las tareas en progreso del diseño y desarrollo, y fácilmente te deja exportarlas. También tiene un cliente mobile muy sencillo.
  • JIRA - Una plataforma totalmente personalizable donde puedes fácilmente crear tableros para llevar cuenta de actividades como back-end, front-end, diseño, etc. Y creo que si bien el cliente mobile es un poco débil, es una gran solución para grandes equipos que incluyen bug tracking.
  • Email - Esto es genial para comenzar una conversación o mandar imágenes. Pero por favor, ten cuidado si utilizas emails para enviar críticas u observaciones. Las cosas pueden perderse fácilmente.
También puedes probar Trello y otro software de gestión de proyecto, pero el más usado en nuestra industria son Basecamp y JIRA. De nuevo, lo más importante es encontrar un sistema de gestión de proyecto que todos puedan usar de forma consistente, de otro modo no tiene sentido alguno.

El Diseño UX Y El Desarrollo Se Juntan

El diseñador y desarrollador son una combinación poderosa. Asegúrate de compartir ideas de UI y UX juntos lo más seguido posible. Desarrolladores deberán estar dispuestos a ayudar al diseñador a crear ideas, mientras que un diseñador debe al menos tener un básico conocimiento de las tecnologías que se están utilizando.
Pónganse de acuerdo juntos en cuanto al proceso de trabajo de diseño. No simplemente implementes a ciegas lo que tus diseñadores crean. Sé proactivo, y crea algo que se vea hermoso pero que tenga una gran experiencia de usuario al tomar ventaja de tus dos distintas perspectivas. Los diseñadores pensarán fuera de la caja y ver animaciones locas, ideas, píxeles y botones, mientras que los desarrolladores ven la tecnología, límites y sacudida de velocidades.
Al seguir este tutorial en diseño UI, obtendrás claridad en tu proceso de trabajo de diseño.
En mi experiencia, cada diseñador se pone como loco por los píxeles y conceptos interesantes, pero a veces, un diseñador llega al punto donde tienen una idea, pero el desarrollador los detiene y dice, “Esto no va a funcionar bien una vez que esté implementado. Habrá problemas de desempeño en el consumo”. Recientemente, estaba pensando en implementar una ventana modal con un fondo fuera de foco, pero ese fuera de foco casuaba que los tiempos de carga de imágen fueran muy pesados. Para resolver esto, el desarrollador sugirió utilizar una capa de color simple, la cual cargaría más rápido y mantendría la calidad de la imagen. Diseñadores, póngan atención: No comprometan la experiencia de usuario por el diseño.

El Círculo De Las Observaciones

Las observaciones del diseñador son cruciales, y tiene que ocurrir cuantas veces sea posible. Es probable que sea lo que más tiempo (y energía) te demande, pero necesitarás adoptarlo para poder entregar resultados perfectos. A continuación, un par de consejos en el proceso de trabajo de diseño UX y UI para hace de tus observaciones algo perfecto.
  • Sé visual - Las observaciones y críticas deben ser lo más específicas posible. La mejor manera de hacerlo de forma precisa es tomar una captura de pantalla y resaltar el problema que quieres arreglar. Se vería mejor si tuvieras fotos de una implementación actual vs cómo se debería ver. La comunicación visual eliminará el 50% de las preguntas.
  • Sé descriptivo - Las observaciones deberían ser precisas. No puedes simplemente decir “mueve este botón más hacia arriba”. El diseñador siempre debe especificar cuántos píxeles se debería mover a dicho botón, qué espaciado debería ser usado, etc. Siempre incluye una explicación del problema, y la solución apropiada. Va a tomar mucho tiempo, pero vale la pena.
  • Sé paciente - Ten en cuenta que el diseñador y el desarrollador no comparten el mismo enfoque. Si los desarrolladores no entienden por completo la idea de un diseñador, esto puede llevar a malas decisiones. En cada caso, ambos lados deberán ser pacientes y estar dispuestos a ayudar a otros miembros del equipo. Realmente es difícil a veces, pero es una habilidad que todo diseñador y desarrollador debería aprender.
Es bastante obvio que estas cosas necesitan ser combinadas para hacerlas más apropiadas a un proceso de trabajo de diseño. Pero, ¿qué herramienta podría ayudarte para enviar críticas y observaciones?
  • Email - No me da miedo decir que esta es la plataforma más común para enviar observaciones. Está bien usarla, si sigues un par de simples reglas:
    • Primero, usa un sólo hilo de conversación para las observaciones. No pongas cada modificación en un email nuevo con un título diferente.
    • Segundo, crea una lista de arreglos. Intenta sentarte y pensar en cada modificación o arreglo que descrubres.
    • Y por último, no envíes listas masivas por vez. Intenta separarlo en listas individuales pequeñas y ve parte por parte.
  • Skype (Hangouts) - La voz es realmente una herramienta potente para ofrecer crítica constructiva. Inmediatamente puedes preguntar y responder preguntas. Pero asegúrate de tomar notas y enviarlas en el próximo email después de la llamada.
  • Herramientas colaborativas - Para ser honesto, no soy un gran fan de las herramientas de colaboración. Pero tienen un gran beneficio: te ayudan a que el feedback esté en su lugar. Preguntar y responder preguntas es rápido, y se queda ahí por siempre.
A continuación, algunas de las mejores herramientas:
Anotaciones de críticas y observaciones:
Herramientas de colaboración:

Conclusión

Establecer un sistema de proceso de trabajo de diseño UI/UX que mantiene las líneas de comunicación abiertas a través del proceso de diseño y desarrollo. Esto te permitirá implementar grandes ideas, predecir potenciales problemas, y priorizar cuestiones importantes.
El desarrollador y diseñador pueden crear grandes cosas juntos siempre y cuando estén dispuestos a trabajar como un equipo, ¡para aprender en conjunto y crear tutoriales como este!
Articulo originalmente publicado en Toptal.

jueves, 1 de junio de 2017

Los 10 errores más comunes en diseño de aplicaciones móviles

El mercado de las aplicaciones móviles está saturado de competencia. Las tendencias cambian rápidamente, pero ningún nicho de mercado puede durar mucho tiempo sin que varios competidores entren en juego. Estas condiciones dan lugar a una alta tasa de fracaso en todos los ámbitos para el mercado de las aplicaciones móviles. Sólo el 20% de las aplicaciones descargadas ven regresar a los usuarios después del primer uso, mientras que sólo el 3% de las aplicaciones permanecen en uso después del primer mes.
Si cualquier parte de una aplicación no es deseable, o el proceso de entenderla es lento, los usuarios son más propensos a instalar una nueva, en lugar de esperar hasta el final con el producto imperfecto. El consumidor no pierde nada cuando se deshace de una aplicación - excepto los esfuerzos de los diseñadores y desarrolladores. Así que, ¿por qué fallan tantas aplicaciones? ¿Es un fenómeno predecible que los diseñadores de aplicaciones y desarrolladores deben aceptar? Para los clientes, ¿es aceptable ésta tasa de éxito? ¿Qué se necesita para llevar tus diseños al 3% de las aplicaciones prósperas?
Los errores más comunes van desde no mantener la constancia a lo largo de la vida útil de una aplicación, hasta atraer a los usuarios en primer lugar. ¿Cómo pueden ser diseñadas las aplicaciones con una simplicidad intuitiva, sin llegar a ser repetitivas y aburridas? ¿Cómo puede una aplicación ofrecer todos los detalles agradables, sin perder de vista un propósito mayor? La mayoría de las aplicaciones viven y mueren en los primeros días, así que aquí están los diez errores más comunes que los diseñadores pueden evitar.
Sólo el 3% de las aplicaciones móviles se mantienen en uso después de ser descargadas.

Error Común # 1: Una Primer Mala Impresión

A menudo, el primer uso, o el primer día con una aplicación, es el período más crítico para atraer a un potencial usuario. La primera impresión es tan crítica que podría ser un punto de partida para el resto de éste top 10. Si algo no está bien, o parece confuso o aburrido, los usuarios potenciales pierden interés rápidamente; aunque, el equilibrio apropiado para la primera impresión es difícil de lograr. En algunos casos, un largo proceso de integración (onboarding), o un proceso para descubrir características necesarias pueden aburrir a los usuarios.
Sin embargo, una aplicación que sea tentadora instantáneamente puede pasar por alto la necesidad de un tutorial adecuado, y promover la confusión. Se debe encontrar el equilibrio entre una aplicación que es inmediatamente intuitiva, y que también introduzca a los usuarios a las características más divertidas y atractivas con rapidez. Ten en cuenta que cuando los usuarios llegan a tu aplicación, la están viendo por primera vez. Es importante tener un proceso de prueba adecuado para determinar cómo los demás perciben tu aplicación desde el principio. Lo que parece obvio para el equipo de diseño, puede que no lo sea para los recién llegados.

Integración Inadecuada

La integración o incorporación es el proceso paso a paso de la introducción de un usuario a tu aplicación. Aunque puede ser una buena manera de orientar a alguien de forma rápida, la integración también puede ser un proceso prolongado que se interpone en el camino de tus usuarios y su contenido. A menudo, estos tutoriales son demasiado largos, y es probable que los lean por encima.
A veces, los usuarios han visto que tu aplicación es utilizada en público o en algún otro lugar, de tal manera que llegan a entenderla de una vez y quieren usarla a la primera. Por lo tanto, permite una especie de estrategia de salida rápida para evitar por completo el bloqueo de la aplicación a partir de su primer uso. Para asegurarte que el proceso de incorporación es de hecho efectivo, debes tener en cuenta qué valores esto puede comunicar y cómo hacerlo. El proceso de integración debe demostrar el valor de la aplicación con el fin de enganchar un usuario, en lugar de sólo una explicación.

No Sobrecargues la Animación en el Inicio

Algunos diseñadores deciden dar una buena primera impresión con animaciones de entrada, que sean fascinantes y deslumbren a los nuevos usuarios. Sin embargo, ten en cuenta que cada vez que alguien quiere ejecutar la aplicación, va a tener que ver la misma cosa una y otra vez. Si la aplicación tiene una función diaria, entonces esto va a cansar a tus usuarios de forma rápida. Diez segundos del día de alguien para deslizar un logo por la pantalla y tal vez hacerlo girar un par de veces en realidad no vale la pena después de un tiempo.

Error Común # 2: Diseñar una Aplicación sin Propósito

Evita entrar en el proceso de diseño sin intenciones concisas. Las aplicaciones son a menudo diseñadas y desarrolladas con el fin de seguir las tendencias, en lugar de resolver un problema, llenar un nicho, u ofrecer un servicio distintivo. ¿Cuál es la ambición de la aplicación? Para el diseñador y su equipo, el sentido de propósito afectará cada paso de un proyecto. Esta sensibilidad guiará cada decisión de la marca o la comercialización de una aplicación, con el formato de wireframe, y un botón estético. Si el propósito es claro, cada pieza de la aplicación comunicará y funcionará como un todo coherente. Por lo tanto, asegúrate de que el equipo de diseño y desarrollo considere continuamente sus decisiones dentro de un objetivo mayor. A medida que avanza el proyecto, la ambición inicial puede cambiar. Esto está bien, siempre y cuando la visión siga siendo coherente.
Transmitir esta visión a tus usuarios potenciales significa que van a entender qué valor traerá la aplicación a sus vidas. Por lo tanto, esta visión es algo importante que se debe transmitir en la primera impresión. La pregunta es, ¿qué tan rápido puedes convencer a los usuarios de tu visión para la aplicación? Cómo se va a mejorar la vida de una persona, o proporcionar algún tipo de goce o comodidad. Si esta ambición es difundida eficazmente, entonces, siempre y cuando tu aplicación sea en realidad útil, llegará al 3%.
A menudo, unirse a un mercado pre-existente, o una aplicación del nicho de mercado, significa que hay aplicaciones que estudiar, mientras diseñas tu propia aplicación. Por lo tanto, ten cuidado de cómo eliges ‘dar nuevo propósito’ a lo que ya está en el mercado. Estudia el mercado de las aplicaciones existentes en lugar de solo revisar. Entonces, mejora a partir de productos existentes, en lugar de imitar sin pensar.

Error Común # 3: Desaprovechar el Diseño de Mapeo en UX

Ten cuidado de no pasar por alto una planificación cuidadosa de la arquitectura UX de una aplicación antes de comenzar un trabajo de diseño. Incluso antes de llegar a una etapa de wireframing, el flujo y la estructura de una aplicación deben ser mapeados.
Los diseñadores están, a menudo, demasiado emocionados como para producir la estética y detalles. Esto da lugar a una cultura de diseñadores que generalmente no aprecian el UX ni la lógica o la navegación necesaria dentro de una aplicación. Ve más despacio. Esboza el flujo de la aplicación primero antes de preocuparte demasiado por las pinceladas más finas. A menudo, las aplicaciones fallan por una falta general de flujo y organización, en lugar de datos imperfectos. Sin embargo, una vez que el proceso de diseño comienza siempre se debe mantener el objetivo principal en mente. Los detalles y estética deberían entonces evocar claramente el concepto primordial.

Error Común # 4: No Tomar en Cuenta el Presupuesto de Desarrollo de la Aplicación

Tan pronto como se dibuja la base de la aplicación, es un buen momento para obtener un presupuesto del equipo de desarrollo. De esta manera no se llega al final del proyecto y de repente se necesita empezar a eliminar características críticas. A medida que desarrollas tu carrera de diseño, siempre toma nota de los costos regulares de construcción de tus conceptos para que tu pensamiento de diseño corresponda con restricciones económicas. Los presupuestos deben ser las restricciones de diseño útiles dentro de las cuales se puede trabajar.
Muchas aplicaciones fallidas tratan de cargar demasiadas funciones desde su lanzamiento.

Error Común # 5: Sobrecarga de Características de Diseño

Con suerte, un riguroso wireframing marcará claramente la diferencia entre las funciones necesarias y las excesivas. La plataforma ya es la “navaja suiza” definitiva, por lo que tu aplicación no tiene que serlo. No sólo el sobrecargar una aplicación con características puede conducir a una probable experiencia de desorientación para el usuario, pero una aplicación sobresaturada también será difícil de comercializar. Si el uso de la aplicación es difícil de explicar de una manera concisa, lo más probable es que esta esté tratando de hacer demasiado. Disminuir características siempre es difícil, pero necesario. A menudo, la mejor estrategia podría ser la de ganar confianza desde el principio con una o algunas funciones, y más adelante en la vida de la aplicación se pueden “probar” las nuevas. De esta manera, las características adicionales son menos propensas a interferir con los cruciales primeros días de vida de una aplicación.

Error Común # 6: Descartar el Contexto de la Aplicación

Aunque las condiciones de la mayoría de las oficinas de diseño prácticamente operan en un vacío, los diseñadores de aplicaciones deben estar al tanto de contextos más amplios. Aunque el propósito y la ambición son importantes, se vuelven irrelevantes si no se dirigen en el contexto adecuado. Recuerda que aunque tú y tu equipo de diseño conocen la aplicación muy bien, y les parezca evidente la interfaz del usuario, esto puede no ser el caso para los nuevos usuarios, o diferentes grupos demográficos.
Ten en cuenta el contexto inmediato o situación en la que se pretende utilizar la aplicación. Teniendo en cuenta la situación social, ¿cuánto tiempo puede la persona considerar utilizar la aplicación? ¿Qué otra cosa podría ser útil para ellos encontrar dada la circunstancia? Por ejemplo, la interfaz UBER sobresale ya que se utiliza con mucha rapidez. Esto significa que en su mayor parte, no hay mucho espacio para otro tipo de contenido. Esto es perfecto porque cuando un usuario está fuera con sus amigos y necesita reservar un viaje, su conversación es poco interrumpida en el proceso. UBER esconde una gran cantidad de contenido de soporte dentro de la aplicación, pero sólo aparece una vez que el escenario lo requiere.
¿Quién es el público objetivo de la aplicación? ¿Cómo podría el tipo de usuario influir cómo es el diseño de la aplicación? Tal vez, debes considerar que una aplicación específica para un usuario más joven puede ser capaz de tomar más libertades asumiendo un cierto nivel de intuición por parte del usuario. Considerando que muchas funciones pueden necesitar ser señaladas específicamente para un usuario menos conocedor de la tecnología. ¿Tu aplicación está destinada a ser visitada de forma rápida y por un corto período de tiempo? O, ¿es una aplicación con una gran cantidad de contenido que permite a los usuarios quedarse en ella un tiempo? ¿Cómo será el diseño para transmitir este tipo de uso?
Un buen diseño de aplicación debe considerar el contexto en el que se utiliza.

Error Común # 7: La Subestimación del Cross-Platform

A menudo, las aplicaciones se desarrollan rápidamente como respuesta a los cambios del mercado o competidores que avanzan. Esto suele resultar en contenido web siendo arrastrado a la plataforma móvil. Un tema constante, lo que se podría pensar sería ampliamente entendido ahora, sucede tan a menudo que las aplicaciones y otros contenidos para móviles hacen transiciones pobres entre el escritorio, o plataformas móviles. Ya no es posible que el diseño móvil haga reducción gradual de contenido web sin consecuencias con la esperanza de conseguir rápido un negocio en el mercado móvil. La transición de web a móvil no sólo significa reducir todo, sino también ser capaz de trabajar con menos. Las funciones, navegación y el contenido deben ser transportados con mínima estrategia.
Otro problema común aparece cuando un equipo de desarrollo de aplicación aspira a lanzar un producto al mismo tiempo en todas las plataformas, y través de diferentes tiendas de aplicaciones. Esto a menudo resulta en una compatibilidad pobre, o en general, una aplicación con errores y sin pulir. La gimnasia que implica un equilibrio de múltiples plataformas puede ser demasiado para sumarse al lanzamiento de una aplicación. Sin embargo, a veces no hace daño llevarlo lentamente con un sistema operativo a la vez y corregir los problemas principales, antes de preocuparse por la compatibilidad entre plataformas.

Error Común # 8: El Diseño de la Aplicación es Demasiado Complicado

El famoso arquitecto Mies Van der Rohe dijo una vez: “Es mejor ser bueno que ser único”. Asegúrate de que tu diseño esté cumpliendo con lo acordado antes de empezar a romper la caja o agregar adornos. Cuando un diseñador se encuentra a sí mismo añadiendo detalles a fin de hacer una composición más atractiva o emocionante, estas opciones, es probable, que carezcan de mucho valor. Seguir preguntando a lo largo del proceso de diseño, ¿cuánto puedo quitar? En lugar de diseñar de forma aditiva, diseña de forma reductora. ¿Qué no se necesita? Este método está dirigido tanto hacia el contenido, el concepto y la función, como a la estética.
La complejidad excesiva es a menudo el resultado de un diseño que innecesariamente rompe convenciones. Varios símbolos e interfaces son estándar dentro de nuestro lenguaje visual y táctil. ¿Tu producto realmente podrá beneficiarse de la reelaboración de estos estándares? Iconos Estándar han demostrado ser universalmente intuitivos. Por lo tanto, a menudo son la forma más rápida de proporcionar indicaciones visuales sin llenar innecesariamente una pantalla. No dejes que tus detalles de diseño interrumpan el contenido real ni el funcionamiento de la aplicación. A menudo, a las aplicaciones no se les da suficiente espacio en blanco. La necesidad de espacio en blanco es un concepto gráfico que ha trascendido tanto lo digital como lo impreso, por lo que no debe subestimarse. Mantén un espacio entre los elementos en la pantalla, de modo que todo el trabajo que pusiste en la navegación y UX se pueda sentir.
El proceso de diseño de aplicaciones puede ser reductor, en lugar de aditivo

Error Común # 9: Inconsistencias de Diseño

En cuanto a la simplicidad, si un diseño va a introducir nuevos estándares, deben ser por lo menos equilibrados en toda la aplicación. Cada nueva función o parte del contenido no necesariamente tiene que ser una oportunidad para introducir un nuevo concepto de diseño. ¿Los textos están formateados de manera uniforme? ¿Los elementos de la interfaz se comportan de manera predecible, pero agradable a lo largo de la aplicación?
La coherencia del diseño debe encontrar el equilibrio entre la existente dentro del lenguaje visual común, así como evitar estar estéticamente estancada. El equilibrio entre la consistencia intuitiva y el aburrimiento es una línea muy fina.

Error Común # 10: Desaprovechar App Beta Testings

Todos los diseñadores deben analizar el uso de sus aplicaciones con algún tipo de ciclo de retroalimentación con el fin de aprender lo que está y no está funcionando. Un error común en las pruebas es que un equipo haga sus pruebas beta con sus propios miembros. Es necesario traer ojos frescos con el fin de excavar realmente en los borradores de la aplicación.
Envía un anuncio buscando probadores beta y trabaja con un grupo selecto antes de anunciarlo al público. Esto puede ser una gran manera de limar detalles, editar características, y encontrar lo que falta. A pesar de que las pruebas beta pueden llevar mucho tiempo, puede ser una mejor alternativa que desarrollar una aplicación que fracase. Anticipa que las pruebas a menudo toman 8 semanas para algunos desarrolladores para poder hacerlo correctamente. Evita el uso de amigos o compañeros de trabajo como probadores, ya que no pueden criticar la aplicación con la honestidad que necesitas. El uso de los blogs de aplicación o páginas web para revisar tu aplicación es otra manera de probar la aplicación en un lugar público sin un lanzamiento completo. Si estás teniendo dificultades al disminuir características para tu aplicación, esta es una buena oportunidad para ver qué elementos importan o no.
El mercado de diseño de aplicaciones es un campo de batalla, por lo que el diseño de productos que son sólo adecuados simplemente no es suficiente. Encuentra una manera de conectar a los usuarios desde el principio - comunicar y demostrar los valores críticos y características tan pronto como sea posible. Para poder hacer esto, el equipo de diseño debe tener una visión coherente de lo que la aplicación desea lograr. Para establecer esta ambición, un proceso de story-boarding riguroso puede limar lo que es y no es imprescindible. Considera qué tipos de usuarios encajarían mejor con la aplicación. Y luego, refina y perfecciona hasta que absolutamente nada más puede ser eliminado del proyecto sin que éste se caiga a pedazos.
Articulo originalmente publicado en Toptal.