miércoles, 28 de septiembre de 2016

Diseñando un Mejor Portal Web: Los Fundamentos Primero

Cuántas veces has terminado un proyecto, sólo para mirar atrás y decir: “¡Si tan sólo pudiera regresar en el tiempo y hacerlo todo de nuevo con lo que sé ahora!?” Al menos yo lo he pensado.
A todos nos pasa; estamos emocionados por un nuevo proyecto. Hacemos chistes con el cliente sobre el sitio web actual, firmamos los contratos y luego comienzan los planes y prototipos. Cuando se trata de proyectos pequeños este tipo de estrategias podrían funcionar. Pero cuando se trata de proyectos grandes, el crecimiento repentino y cambios no planeados después de la primera presentación. Y si llegas a terminar el proyecto, probablemente acabarás con una monstruosidad que se parece a lo que debías arreglar, sólo que éste lucirá un poco mejor que el original.
Un buen diseño y una buena experiencia de usuario no empiezan con un prototipo o maqueta atractiva, o con un plano, sino con una base conceptual que se centra en los objetivos de la empresa. Y dichos objetivos no son “Hagamos un sitio web más sencillo y bonito.” Como tú eres responsable de la UX y UI (Experiencia de Usuario e Interfaz del Usuario), por lo que es necesario asegurarse que los usuarios tengan la mejor experiencia en la interfaz que se está diseñando. Y para lograr esto, se debe planificar a fondo desde el principio.

Investigación Inicial para el Diseño de Páginas Web

Una vez que se termina la investigación inicial del campo del cliente y el de su competencia, lo siguiente es saber con qué se va comenzar. Se puede tener un precio separado para este análisis (que se incluirá en la cotización final del proyecto). Esto evitará cotizaciones altas y ambiguas que supuestamente incluirán cualquier ítem que salga más adelante.
El cliente que se tratará como ejemplo es una organización sin fines de lucro en el campo de la arqueología. La compañía explora y protege sitios arqueológicos en el sur-oeste del país. Actualmente, el sitio web está descomunalmente desorganizado. Imagina montañas y montañas de contenido poco organizado en un antiguo portal cms. Teniendo esto en cuenta, el primer paso es organizar el contenido.

Paso 1: Familiarización con el contenido

Cuando estás construyendo una casa nueva, no derrumbas todas las paredes sin antes sacar lo que está dentro de la misma. El primer objetivo sería ir dentro de todas las habitaciones y sacar todo el contenido. En diseño hablado (Design Speak), debemos ir a todas las entradas y determinar cuáles deberían ser estáticas y cuales tienen material para ser tipo post.

Paso 2: Creación del Enfoque, Simplificación y Organización

Con el contenido de la casa fuera de la misma, empaquetado y etiquetado, es momento de hacer los planos para una nueva casa que tendrá un mejor estilo y mostrará el contenido de mejor manera. Pero antes de llegar a ello, se debe crear el enfoque.
Según el cliente, los usuarios que visitan la página web buscan información sobre arqueología, tanto como sus proyectos de investigación, ver los próximos eventos, o leer la revista mensual. A pesar de que estas son las áreas de contenido es donde terminan los usuarios, el sitio web no se desenvuelve en torno a ellas; para poder encontrar el foco del portal, debes prestar atención al núcleo de la organización.
Se delimitó que la “localización” está en el centro de los contenidos. Sin la ubicación o localización no existirían los sitios arqueológicos, ruinas, museos o exposiciones. En el fondo, la arqueología se desenvuelve en torno a las ubicaciones.
Una vez se tiene el enfoque es momento de simplificar y organizar. Abajo, se despliega el contenido que se sacó del sitio que no tenía relación con ubicaciones, tales como las páginas del equipo, informes anuales, y así sucesivamente. Luego de ordenar y categorizar el contenido, se obtuvo este mapa:
Website Design Workflow

Paso 3: Looping al Cliente

En el mapa del sitio exhibido con anterioridad, se incluyen los tipos de páginas pero no el mapa de los contenidos. Como de seguro ya sabrán, la mayoría de los problemas se producen una vez el cliente comienza a agregar contenido al sitio. Para evitar esta situación se hace un loop con el cliente desde el principio. Lo siguiente es crear un documento de Google con el mapa del sitio que tenemos, y luego enviárselo al cliente para que nos diga cuál es el contenido actual y cómo lo quiere mapear en la nueva estructura.
Si algo no encaja se puede resolver más adelante. Esto es uno de los pasos más importantes, debido a que no sólo involucra al cliente sino que también nos deja saber cualquier problema de la estructura antes de comience la implementación. Para el proyecto que estamos tratando, resultó que se cambiaron algunos elementos del mapa del sitio con respecto al menú; cómo el cliente tenía varias páginas de donaciones, la solución fue crear un post único para las mismas.

Creación de Estructura Visual a través de Wireframing

Lo siguiente es crear una estructura visual para el sitio. Para que la función del sistema trabaje exitosamente, y para lograr la idea de “todo relacionado a la ubicación”, se creó una relación bidireccional entre los diferentes tipos de posts.
Esta es la idea: Cuando un visitante llega al sitio de arqueología y escoge el Gran Cañón, no sólo verá la información sobre el lugar, sino que también encontrará los eventos, proyectos, exposiciones y cualquier otra cosa que el cliente haya enlazado en relación a la página del Gran Cañón. Y así terminamos con algo como esto:
Website Design Workflow
La página de índice de ubicaciones muestra los lugares más recientes en la parte superior. La barra de búsqueda es lo primero que verá el usuario al entrar en la página. Cuando el usuario entra en el sitio, podrá ver el mapa de Google en un 80% de la pantalla, y cuando escoja un punto en el mismo o van viendo la página, aparecerán la red de listas para facilitar su búsqueda.
En una página individual de ubicación la navegación principal estará a la izquierda, debido a que es la información más relevante, mientras que la información meta relacionada al lugar estará a la derecha. Cuando se diseña un plano, para obtener una buena composición se debe tener bloques de elementos primarios, secundarios y terciarios bien definidos. Así el ojo humano seguirá cada uno sin quedarse estancado en un solo elemento.
En este diseño, el usuario empezará en la cabecera del sitio, y luego continuará hacia el bloque de contenido, y después la información a la derecha. Cada segmento de contenido relacionado se muestra en orden de relevancia e importancia. Si el usuario está leyendo sobre el Gran Cañón, por ejemplo, probablemente a esto le seguirán fotos y un mapa del lugar.
Este sitio es esencialmente educacional, por lo que después vendrá “En relación a esta ubicación”. Debido a que el cliente no tiene mucha información única asociada con cada ubicación, se combinó el contenido apenas usado en un bloque exclusivo debajo del menú del sitio.
Colocando miniaturas de la revista y los videos en contenido relacionado añade elementos visuales adicionales y guía a los usuarios hacia la página de “compra”. La página está terminada al mostrarle las ubicaciones, ya que esto incentiva a los usuarios a seguir explorando el sitio web.
El siguiente paso es continuar con esta estructura para otros tipos de posts. Éstos son algunos de ellos:
Better Website Design Workflow
Ahora que se tiene un modelo general para los tipos de posts, me puedo concentrar en la página principal. Al igual que con todo interfaz de usuario, el primer paso es llegar a la meta de la página principal. La investigación del cliente mostró que muchos usuarios se tropiezan con el sitio sin entender completamente lo que es. Por lo tanto, una introducción y un texto de bienvenida debe ser lo primero que ven los usuarios. El nuevo enfoque central gira en torno a lugares y éste debe ser el bloque secundario, seguido de lo que está pasando en ArchaeologySouthwest.org (la revista actual, blog, eventos, noticias, etc.). Esta es la iteración del proceso de diseño:
Better Website Design Workflow
Con V1, se creó un diseño básico que se asemeja a la página inicial. No hay mucha jerarquía; lo primero que un usuario verá es el lugar destacado y luego se perderá en las columnas. Con V2, se creó una columna separada que hace que sea más fácil de seguir. Sin embargo, todavía se puede mejorar. Aquí es donde el conocimiento del contenido juega un papel importante. Se sabe que ArchaeologySouthwest.org no tiene más de dos eventos sucediendo a la vez, por lo que no tiene sentido tener muchos en la página de inicio. En V3, el foco está en los próximos eventos de manera que si va a haber más de dos, el usuario puede hacer clic en un botón “más” y ver el resto. También se hizo un énfasis adicional en la revista actual, ya que es fuente de dinero del cliente. Los usuarios comienzan en la parte superior y con el uso de un patrón F, se mueven hacia abajo. Así que ahora, el flujo del ojo es Localización> Bienvenido> Revista> Eventos> Noticias.
Ahora que se tiene un wireframe visual y estructura del sitio es mucho más fácil solidificar características y cómo funcionarán las cosas. Se tiene otra reunión con el cliente para repasar la funcionalidad real (que ahora sale a la luz) y el flujo de la interacción del usuario. Se sabe que todavía habrá ajustes en el final, pero serán solo ajustes y no cambios en todo el proceso. Lo más importante es que no habrá sorpresas.
Fuente:
Alex Gurevich Desiigners Vea el Post original AQUI

(En línea) (traducido del inglés).

jueves, 15 de septiembre de 2016

Init.js: Una guía de los Por Qué y Cómos en el conjunto de tecnologías de JavaScript

La Historia

Entonces, tú y tu cofundador tienen esta genial idea para un negocio, ¿verdad?
Has estado agregando características en tu cabeza.
Frecuentemente, le preguntas a tus potenciales clientes sus opiniones, y todos ellos la aman.
Ok, entonces la gente la quiere. Hay hasta un poco de dinero para hacer. Y la única razón por la cual ellos no pueden obtenerla es porque no las has implementado—todavía.
Entonces, finalmente, te sientas un día y dices “¡Hagámoslo!”. Pronto, estás tratando de averiguar cómo aplicar la lógica de negocio de tu aplicación, la funcionalidad asesina que va a llevar adelante al producto: tienes una idea de cómo hacerlo, y ahora sabes que puedes hacerlo.
“¡Listo!¡Funciona!” dices. ¡Tu prueba de concepto es un éxito! Todo lo que queda por hacer es empaquetarlo en una aplicación web.
“Ok, hagamos el sitio”, dices.
Y entonces, te das cuenta de la verdad: necesitas elegir un lenguaje de programación; necesitas elegir una plataforma (moderna); necesitas elegir algunos frameworks (modernos); necesitas configurar (y comprar) espacio, base de datos y proveedores de alojamiento; necesitas una interfaz de administración; necesitas un sistema de permisos; necesitas un administrador de contenidos.
Quieres ser escueto, quieres ser ágil. Quieres usar tecnologías que te ayudaran a tener éxito en el corto-y largo-plazo. Y no son siempre fáciles de elegir
Tienes que tomar decenas y decenas de decisiones de arquitectura . Y quieres tomar las correctas: quieres usar tecnologías que te permitan desarrollo rápido, iteración constante, máxima eficiencia, velocidad, robustez y más. Quieres ser escueto, quieres ser ágil. Quieres usar tecnologías que te ayudaran a tener éxito en el corto-y largo-plazo. Y no son siempre fáciles de elegir.
“Estoy abrumado”, dices, mientras te vas sintiendo abrumado. Tu energía no es la misma de antes. Tratas de encajar las piezas, pero es demasiado trabajo.
Tu prueba de concepto se marchita y muere lentamente.

La Propuesta

Luego de abandonar toneladas de ideas de esta forma, decidí diseñar una solución. La llamo el proyecto ‘Init’ (Inicio)(ó init.js).
El corazón de la idea es tener un simple proyecto que inicie todos los demás, dejar que el desarrollador o el fundador técnico tomen esas decisiones al mismo tiempo y recibir una plantilla apropiada para empezar basada en esas decisiones. Se lo que van a decir los detractores, “Una solución no puede aplicarse a todos los problemas” (Odiadores odiarán). Y puede que estén en lo cierto. Pero podemos hacer nuestro mejor esfuerzo para crear una solución aproximada, y creo que Init se acerca bastante.
Para lograr mejor este objetivo, tenemos que tener algunas ideas claves en mente. Cuando estaba desarrollando Init, consideré:
  • Componentes
    La modularización es una característica clave de cualquier sistema ya que te permite reusar componentes de software a través de distintos proyectos—lo cual es el principal objetivo de Init. Pero la modularización también viene con una “reemplazabilidad” por producto, la cual será nuestra mejor aliada a la hora de atacar varios tipos de problemas con “casi” la misma solución.
  • Facilidad de Desarrollo
    Para algunos problemas, en algún lado hay una mejor solución escrita en [Brainf*ck](https://en.wikipedia.org/wiki/Brainfuck). ó jodecerebros). Pero implementar esa solución (en Brainf*uck) sería casi imposible de escribir, y mucho menos de leer. Te costaría tiempo y una enorme cantidad de esfuerzo. En general, deberías usar lenguajes y plataformas que hagan al desarrollo fácil, y no difícil para tí (o alguien que puede trabajar con él más tarde).
  • Comunidad
    Cualquier plataforma que elijas, asegúrate que tenga una gran comunidad, y una que te pueda ayudar con los problemas más comunes y con los que no lo son tanto. Recuerda: jQuery puede no ser la librería másrápida, la más limpia, o la más elegante—pero es un ganador sólo por su comunidad.
Teniendo estos objetivos en mente, voy a mostrarte como hice mis propias decisiones al crear Init.
En su núcleo, Init se aprovecha del paradigma ‘full-stack JavaScript’ (algunas personas se refieren a él, o a una parte de él, como el MEAN Stack). Al trabajar con este conjunto, Init es capaz de usar solamente un sólo lenguaje mientras crea un ambiente increíblemente flexible y con todas las funciones para desarrollar aplicaciones web. En resumen, Init te permite usar JavaScript no solamente para desarrollo del lado cliente y servidor, pero también para construir, testear, maquetar, y más.
Pero bajemos un poco la velocidad y preguntémonos: ¿es realmente una buena idea usar JavaScript?

Por qué elegí JavaScript

Soy desarrollador web desde 1998. Por esas épocas usabamos Perl para la mayoría de nuestro desarrollo del lado del servidor, y aún desde esos tiempos teníamos JavaScript del lado del cliente. Las tecnologías web del lado servidor han cambiado inmensamente desde entonces: fuimos a través de oleada tras oleada de distintas tecnologías y lenguajes cómo PHP, ASP, JSP, .NET, Ruby, Python, solo por nombrar algunas. Los desarrolladores comenzaron a darse cuenta que usando dos distintos lenguajes para ambientes cliente y servidor estaba complicando las cosas. Los intentos iniciales para unificar bajo un mismo lenguaje intentaban crear componentes cliente del lado del servidor y compilarlos en JavaScript. Esto no funcionaba como se esperaba y muchos de esos proyectos fallaron (por ejemplo, ASP MVC reemplazando los formularios web de ASP.NET, y podría decirse queGWT será reemplazado por Polymer). en un futuro cercano). Pero era una excelente idea, en esencia: un lenguaje único en el cliente y el servidor, permitiéndonos reusar componentes y recursos (esta es la clave:recursos).
Fuente:
BY ALEJANDRO HERNANDEZ - JAVASCRIPT DEVELOPER @ TOPTAL(TRANSLATED BY PABLO FABREGAT
en: Developers AQUI