indexante : usablidad y desarrollo web

Buenos Aires en tiempo real, un experimento

cesars — Wed, 16 May 2012 18:06:23 +0000

Este es un experimento que trabaja con tiempo real. Muestra la actividad en vivo de usuarios en ciudades como: Buenos Aires, Santiago, Madrid y Lima. La idea es probar con desarrollo web distinto al tradicional y analizar la data. Por ahora usa info de Instagram, aún esta en desarrollo.

Los datos técnicos: Construido enteramente usando Javascript, Jquery y la excelente libreria Gmaps.js en frontend, NodeJS como servidor es excelente para este tipo de aplicaciones, pero te cambia el paradigma de programación a construir completamente asíncrono, y Redis, una base de datos No SQL, todo en pro de construir aplicaciones veloces.

Como es costumbre de la casa, la sugerencias son bienvenidas, pronto iré actualizando el experimento.

Lo que interesa

cesars — Wed, 09 May 2012 15:49:13 +0000

No me interesa para que fue diseñado, me interesa lo que es capaz de hacer.

Gene Kranz en Apollo 13 (1995)

Sobre Arquitectura de Información en WebInc

cesars — Sat, 05 May 2012 23:35:59 +0000

Conversar con Antonio Ognio y Germán Martínez, siempre es divertido. Esta vez me invitaron a su programa y hablamos un poco de Arquitectura de Información, proyectos y más. Dejo el video, y por supuesto sígalos cada semana en WebInc.

Un manual para el periodismo de datos

cesars — Thu, 03 May 2012 21:01:49 +0000

The Data Journalism Handbook, es un manual colaborativo para aprender lo esencial del periodismo de datos. Está dirigido a periodistas, programadores y diseñadores que trabajan en medios digitales. El libro es demostrativo, se explican el por qué y cómo de trabajos desarrollados en sitios como BBC, Chicago Tribune, La Nación o The Guardian.

Aún en versión beta, el libro esta disponible online de libre acceso y copia.

Periodistas que programan y otros mitos

cesars — Wed, 25 Apr 2012 16:17:57 +0000

Existe un corriente entusiasta que dice que los periodistas deben saber programar, la idea de fondo es que si un periodista alcanza la habilidad de desarrollar software tendremos un ser mítico en la redacción que ideará y construirá el futuro de los medios digitales, casi como una oferta de dos por uno, pero es un error pensar así.

Programar es una disciplina de lógica y concentración, no es lo mismo aprender PHP que aprender a programar, resolver problemas complejos en lineas de código y alta tolerancia a la frustración a tiempo completo son algunas cosas que se requieren para ser un buen programador, y esto no se logra con un curso breve, sino con práctica constante de años.

Pero no me malinterprete, si un periodista quiere programar bienvenido sea al equipo, existen sitios como Codecademy que permiten iniciarse en desarrollo web de manera didáctica, es más lo recomiendo constantemente, la experiencia de resolver problemas a nivel código es aleccionadora. Pero no será suficiente con eso, como decía al principio la práctica hace al maestro.

Creo que quieren resolver un problema de la manera incorrecta, los periodistas no tienen que aprender de programación, tienen que entenderla, y así resolver el problema de fondo: aprender a definir requerimientos funcionales.

Louis Srygley dijo alguna vez "sin análisis de requisitos o sin diseño, programar es el arte de crear errores en un documento de texto vacío", la frase es de una claridad aplastante: el problema de las redacciones con los programadores (y viceversa) es de comunicación, los programadores no entienden qué se quiere construir, los periodistas tienen dificultades para definir qué construir, y en el medio lo queremos para ayer.

El otro problema son los blogs que deforman la idea de construir medios digitales, popularizando la idea de que aprendiendo herramientas online como Pinterest o Instagram se puede reemplazar el desarrollo web en sí mismo, dando la falsa sensación de que el periodista está "programando", asfaltando el camino hacia el #findelperiodismo.

Todos los indicios son claros, tenemos que ponernos de acuerdo en qué construir, pero hasta ahora el mensaje es reemplazar al programador por un ser mítico.

III

Para diseñadores y programadores es más sencillo trabajar con periodistas que entienden las posibilidades del medio.

Existen diversas maneras de escribir requerimientos, desde las de complejidad académica hasta los de sencillez de un to-do list, sea la opción que escoja la clave siempre será la claridad y la precisión, Karl Wiegers definió algunas reglas de estilo para escribir los requerimientos, que sea : factible, necesario, priorizado, no ambiguo, verificable, correcto, todas son características en las que los periodistas son muy hábiles, se ganan la vida escribiendo así!

Recuerde, el problema es la comunicación, y lo que queremos resolver es que todos entendamos qué vamos a construir, la manera de lograrlo es definiendo los requerimientos funcionales. Estas definiciones aportan acuerdo, tiempo y límites al desarrollo, ahorran tiempo, malos entendidos y sorpresas de último momento.

Y esto tiene una ventaja adicional para usted, aprenderá una de las máximas principales de la programación: primero soluciona el problema, luego escribe el código.

Girar a la derecha es ahorrar

cesars — Mon, 02 Apr 2012 17:05:04 +0000

United Parcel Service, más conocida como UPS, una de las empresas más grandes de entrega de paquetes, ahorra millones con el simple hecho de optimizar los recorridos para evitar los giros a la izquierda, que producen esperas y por lo tanto gasto de combustible, esta simple solución a escala de una empresa mundial supone un ahorro importante.

Algo similar sucede en sitios web de escala, las optimizaciones diarias son siempre necesarias, ¿Las personas no se registran? reduzcamos la cantidad de campos de registro a los estrictos necesarios o mejor aún que se registren automaticamente usando su red social preferida, ¿El proceso de pase a producción es lento? hagamos un script que automatize todo con un solo comando en todos los servidores. ¿Publicar una nota es un proceso de varios pasos? reduzcamos todo a una página con un solo botón al final : publicar.

La idea es encontrar esas pequeñas demoras que por si mismas quitan segundos, pero que sumadas nos quitan horas, tiempo que se puede aprovechar en otras tareas.

Open data de la Municipalidad de Lima: sin actualizar

cesars — Thu, 22 Mar 2012 21:20:58 +0000

Anunciada el año pasado, la iniciativa opendata de la Municipalidad de Lima se quedo en el entusiasmo y los retuits. Según comenta la cuenta oficial en Twitter los datos oficiales se actualizan cada 3 meses, pero data como el Directorio de Sanciones, las Licencias de Funcionamiento o Certificados de Defensa Civil siguen sin actualizar desde Setiembre del 2011 y no hay ningún registro para este año.

¿Tenemos que esperar a las elecciones para la actualización?

Son usuarios, no lectores

cesars — Mon, 19 Mar 2012 00:29:53 +0000

Lectores significa un solo flujo de interacción, pasar una hoja o otra, sólo leer. A las personas se les llama según como se conectan con el medio: en un diario eres lector, en la televisión eres televidente.

En la web se les llama usuarios, la interactividad los define, no sólo leen, también comentan, comparten, recomiendan, responden, conversan. Aunque tener una definición parece mínimo, es importante entender ésto como base de cómo se construyen medios digitales.

Libere pronto, trabaje duro

cesars — Fri, 09 Mar 2012 16:39:28 +0000

Sin embargo, quizás la razón más importante para liberar pronto, es que te hace trabajar más duro. Cuando estás trabajando en algo que no se ha liberado, los problemas son interesantes. En algo que está ahí fuera, los problemas son alarmantes. Hay mucha más urgencia una vez que se libera. Y creo que esa es precisamente la razón por la qué la gente lo evita. Saben que tendrán que trabajar mucho más duro cuando lo hagan.

Paul Graham en Las lecciones más difíciles por aprender para una startup, preciso como siempre.

Stack Exchange : UX

cesars — Sun, 04 Mar 2012 20:15:40 +0000

UX es el nuevo foro de la plataforma Stack Exchange, funcionalidad interesante: integra Balsamiq Mockups directamente en el sitio.