Mis primeras impresiones de Objective-C

Objective-C es un lenguaje de programación relativamente desconocido. Sólo recientemente, con el boom de apps para iPhone, es que ha logrado generalizarse su uso un poco más. El nombre como tal provoca cierta curiosidad, dejando entrever sutilmente que hay algo de programación orientada a objetos por un lado, y de C por el otro. Un ingenioso juego de palabras.

Pero el ingenio no se queda sólo en el nombre. El lenguaje en sí es una amalgama entre la dinamicidad de Smalltalk y el inmenso poder y simplicidad de C, dos de los lenguajes mas influyentes en la historia de la computación, y que a primera vista parecerían irreconciliables, pero que Objective-C logra combinar muy exitosamente.

Después de una breve incursión con algo de hobby en el mundo de la programación de apps para iPhone, puedo decir que el lenguaje superó mis expectativas. En este artículo me propongo enumerar brevemente algunas características de este lenguaje que me hacen pensar así.

Es dinámico (aunque no lo parezca)

Aunque pudiera no parecerlo a primera vista, Objective-C es un lenguaje bastante dinámico.

Para empezar, este lenguaje basa su filosofía OOP en el concepto de envío de mensajes entre objetos. Existe una diferencia muy sutil pero importante entre el concepto clásico de lenguajes como C++, en los cuales se dice que se invoca un método de un objeto, y el concepto de lenguajes como Objective-C, Smalltalk y Ruby, en los cuales se habla de enviar mensajes a un objeto.

Lo importante es que esta característica le da a Objective-C una dinamicidad poco común en lenguajes compilados, y le permite hacer uso de estrategias de polimorfismo más liberales, como el conocido Duck typing. En contraste, lenguajes como C++, e incluso lo más dinámicos Java y C#, sólo permiten esta dinamicidad dentro del contexto de clases relacionadas por herencia (polimorfismo clásico).

Otras características que avalan el calificativo de dinámico son:

  • Las clases son también objetos, a su vez instancias de la clase Class. En esto también es similar a Ruby y a Smalltalk, y abre toda una seria de posibilidades dentro del campo de la metaprogramación, como crear métodos y clases dinamicamente en tiempo de ejecución, etc.
  • Type introspection y Reflection, lo que se deriva del punto anterior.
  • Los bloques de código, también similares a los bloques en Ruby, son una característica poco conocida y poco explotada, a pesar de la versatilidad que ofrecen. Para ser justos, es una característica añadida recientemente.

Propiedades declaradas

Objective-C brinda un simple mecanismo para declarar las propiedades o atributos que definen y describen el estado de un objeto, a la vez que se implementa la manera en que estos atributos son accedidos. En esencia, todas las variables de instancia son privadas del objeto, y sus valores solo se pueden acceder y modificar por medio de propiedades y métodos.

La declaración de una propiedad también incluye una serie de características que influyen en la implementación automática de los getters y setters de la misma, como por ejemplo, si la asignación funciona por copia o por referencia, si son thread safe o no, o si la propiedad es de solo lectura, por citar algunos ejemplos.

@interface XYPerson : NSObject {
  NSString *name;  // Variable privada
}

// Propiedad que encapsula la variable
@property (copy) NSString *name;

// ...
NSString *name = somePerson.name;
somePerson.name = @"John Doe";

Esta característica del lenguaje nos permite adherirnos al principio de la encapsulación, una de las bases de la OOP, que permite a cada objeto controlar la manera en que otros objetos acceden a su estado interno y lo manipulan.

Estas propiedades declaradas también juegan un papel importante en algunas de las funcionalidades fundamentales de la runtime library, tales como KVCKVO, etc.

Protocolos

Un protocolo define un contrato, que no es más que un conjunto de métodos, que luego distintas clases pueden adoptar. El protocolo no define implementación alguna, solo el encabezado de los métodos que lo conforman. Cada clase que adopta un protocolo es la que asume la responsabilidad de la implementación.

@protocol XYEnumerator
- (bool)hasNext;
- (id)next;
@end

// Clase que implementa el protocolo
@interface XYArrayEnumerator : NSObject <XYEnumerator>
// Implementación
@end

En este sentido los protocolos de Objective-C son equivalentes a las interfaces de Java y C#, y de hecho se puede decir que son sus precursores también.

Sin embargo, los protocolos, a diferencia de las interfaces de Java y C#, también pueden incluir métodos opcionales, es decir métodos que las clases pueden optar por omitir, dejándolos sin implementación. En este caso, cuando se pretende invocar un método de estos, debe verificarse primero, usando reflection, si el objeto que recibirá el mensaje lo tiene implementado o no.

Otra diferencia es que los protocolos pueden incluir definiciones de métodos de clase, en adición a los métodos de instancia. Y al igual que en Java y C#, una clase puede implementar más de un protocolo.

Un uso obvio para los protocolos consiste en burlar la falta de herencia múltiple, aunque no sólo se limita a esto, como se evidencia en la librería estándar de iOS y Mac OS X, donde abundan protocolos cumpliendo roles como delegatesobservers y demás.

Categorías

Las categorías permiten re-abrir la declaración de una clase para añadirle nuevos métodos, o reemplazar la implementación de métodos ya existentes en la misma. Esto es posible hacerlo con cualquier clase, incluso clases ya compiladas, a cuyo código fuente no tenemos acceso, e incluso a las propias clases de la runtime library.

Muchos puristas de la OOP son contrarios a este tipo de posibilidades en un lenguaje (véase SOLID y Open/Closed Principle), pero yo creo que las ventajas pueden ser mayores que los problemas que pueden venir asociados, si se utiliza inteligentemente. Reconozco que es una característica del lenguaje que se presta para ser utilizada erróneamente, y por lo general el abuso de la misma es un indicio de que el sistema de clases sobre el que se está trabajando no es lo suficientemente sólido y extensible.

No obstante, si se utiliza sabiamente, y no más de lo necesario, puede ser una característica clave en la implementación de un sistema o librería. La prueba de ello está en Ruby, un lenguaje que comparte esta característica, sin la cual un framework como Ruby on Rails no fuera posible tal y como lo conocemos hoy.

Un uso más mundano pero válido para las categorías, es el de separar la implementación de una clase en varios ficheros de código fuente, ya sea por razones organizativas, o porque la implementación es muy extensa y compleja, y la interfaz de la clase se puede separar en grupos relacionados lógicamente.

Compatibilidad con C (y C++)

A diferencia de C++, Objective-C es totalmente compatible con C, siendo este último un subconjunto estricto del primero. Cualquier código en C puro es utilizable en un programa escrito en Objective-C, y las librerías pueden enlazarse sin necesidad de wrappers ni nada por el estilo.

La ventaja más evidente es que los programas Objective-C pueden hacer uso de infinidad de librerías escritas en C, como por ejemplo sqlite y OpenGL, dos ejemplos de uso notable en aplicaciones para iOS especialmente.

También debe mencionarse que Objective-C puede ser combinado con código fuente C++, aunque son lenguajes bastante diferentes. En este caso existen varios requerimientos o restricciones que deben ser observadas.

Conclusiones

El lenguaje, como cualquier otro, está lejos de ser perfecto, y ciertamente tiene algunas características que lo hacen parecer extraño, sobre todo desde el punto de vista sintáctico. También el proceso de inicialización o construcción de objetos es un poco más complejo de lo necesario, en mi opinión.

Mi percepción de este lenguaje ha cambiado con el tiempo. Cuando uno empieza a utilizarlo, aparenta ser algo incómodo y complicado. Pero más temprano que tarde uno comienza a apreciar sus cualidades, a aceptar sus limitaciones y su sintáxis poco convencional, y eventualmente uno llega a gustarle trabajar con él. Especialmente si uno viene de un background de trabajo con otros lenguajes de corte dinámico.

Este artículo sólo pretende rozar la superficie de un tema mucho más amplio y complejo, sin pretender abordar todos los detalles ni tocar todas las aristas.

Espero que su lectura pueda despertar el interés por Objective-C en más de un lector.

PayPal BattleHack Miami

Yeah, we found ourselves in the BattleHack. Acá van mis experiencias del magno evento.

photo (1)

PayPal este año está organizando una tremenda hackatón (alrededor del globo) llamada BattleHack. Como no pudimos competir en la instancia Miami, igual estuvimos allí cubriendo y haciendo networking.

Una gran organización, muchas tremendas ideas, cerca de 100 hackers escribiendo código por 24 horas implementando como lo que son: Hackers que adoran escribir códigos y compartirlo.

Al final los equipos mostraron sus ideas en un pitch de dos minutos donde todos hicieron demos desafiando a Murphy, personalmente yo me ponía más nervioso que ellos, la mayoría salió bien. Algunas demos fallaron, pero siempre todos aplaudieron: todos somos hackers, por ende todos entendemos de qué se trata.

photo (2)

En lo personal estuve apoyando la idea de un par de amigos[1] que al final fue la ganadora (Yep). Se trata de una plataforma que te permite enviar dinero vía PayPal a mercados asociados para retirarlo luego evitando pagar el fee asociado a la transacción (que en Chile es 0 debido al monopolio TransBank, pero en US se cobran entre las redes). Algo notable y como parte del “valor asociado” a los merchants, es que en cada transacción puedes agregar un “good” del merchant, por ejemplo, si se trata de Starbucks tienes la opción de (1) Pedir un café, (2) Donar para organizaciones de caridad, (1) + (2). ¿Bueno, verdad?

Para los interesados en particularidades más técnicas, el equipo ganador usó PHP/JavaScript, Parse (con lo que pudieron aprovechar el mismo backend para el dashboard [merchants] y la app móvil), Google Map, Sendgrid, Twilio y PayPal SDK.

La hackaton comenzó con charlas de hackers de las empresas sponsors, en Miami fueron charlas de Twilio, Sendgrid, Nokia y obviamente PayPal, luego se da el GO.

Durante toda la maratón hay comida, bebidas de todo tipo (menos alcohólicas aunque más de uno trajo su reserva para mantenerse creativo todo el tiempo), colchones de aire para dormir, y los hackers de las empresas sponsors están todo el tiempo disponibles para ayudar en el uso de sus APIs.

El final fue claramente una fiesta, luego que todos presentan sus ideas, hay 45 minutos donde los jueces deciden y la gente hace networking (que por demás es evidente durante todo el torneo).

Hubo tres lugares, cada uno con significativos premios, desde “Robotic programmable balls” para cada miembro del tercer lugar, “Nexus 7″ para cada miembro del segundo, hasta todos los gastos pagos para competir en la gran final para cada miembro del primer lugar en San José, California por nada más y nada menos que el jugoso premio de 100.000 USD al equipo además de la visibilidad en la farándula “Silicon Valley” de su idea.

Además, mientras sucede el evento, se seleccionan: (1) La idea más popular (que coincidentemente ganó el equipo ganador), (2) La idea más avanzada y (3) La idea más hardcode. Al final también cada sponsor selecciona la mejor idea/integración para su API que por cierto Twilio terminó seleccionando coincidentemente también a la ganadora.

Conclusiones: Una gran experiencia, excelente oportunidad para hacer networking, donde por cierto Continuum hizo su aporte haciendo una pequeña demo de RubyMotion en frente del hacker de Twilio que se mostró interesado y finalmente asombrado de ver una aplicación iOS escrita en Ruby y estilizada con CSS usando Pixate.

[1] (@pipozoft & @osnielgonzalez) Que además fundaron en Febrero de este año Vinylfy ganando ya algunos premios con su startup.

El error más común de las startups que buscan empresas de desarrollo

En Continuum trabajamos tanto con startups como con grandes empresas (las llamadas “enterprises”), y nos encanta trabajar con ambos. Pero seríamos ciegos (y giles) si no nos diéramos cuenta que la naturaleza de startups y enterprises difieren lo suficiente como para tener técnicas y formas de trabajo diferentes según cada caso.

Por lo mismo me sorprende muchísimo cuando muchas startups llegan a nosotros y parten de la misma forma que la industria tradicional: Con un “request for proposal” o equivalente, que describe (en mayor o menor detalle) tooodo lo que quieren que diseñemos y construyamos.

Quizás la mayor contribución de Steve Blank (autor del “Startup Owner Manual” y padre del Customer Development) ha sido diseminar la idea de que las startups no son versiones en miniatura de las empresas grandes tradicionales. Las startups son algo diferente. Las startups son una organización dedicada a buscar un modelo de negocios repetible y escalable, y recién una vez que tienen éxito en eso se empiezan a convertir en empresas más tradicionales. Antes no.

Por lo mismo, si tu startup requiere de una empresa (seamos nosotros o sea otro partner) para hacer los primeros MVPs, no imites a las empresas tradicionales. Es un error.

¿Y por qué es un error?

Simple: Por muy buena que sea la visión inicial de una startup, lo primero que hay que hacer es transformar el cerro de hipótesis y suposiciones iniciales en conocimiento y aprendizaje validado. Y construir un MVP es el medio para llegar allí, no el fin en sí mismo. Lamentablemente muchas startups deciden hacer un MVP “big-bang”, que toma un par de meses en desarrollarse y donde se ponen a prueba una docena de hipótesis de una sola vez. En vez de probar hipótesis de a poco, se opta por “construir la app y ver qué pasa”. Citando a Eric Ries:

Desafortunadamente, si el plan es ver qué pasa, un equipo tiene el éxito garantizado — en ver qué pasa — pero no ganará necesariamente aprendizaje validado. Esta es una de las más importantes lecciones del método científico: si no puedes fallar, no puedes aprender.

Y claro, uno cumple el objetivo (ver qué pasa), pero ¿qué pasa si la reacción de los usuarios es tibia (y suele ser así en los primeros MVPs)? ¿Falló la propuesta de valor? ¿O la comunicamos mal? ¿O la app es difícil de usar? ¿O el segmento de usuarios es el equivocado? ¿O genera interés pero no retención? Sepa Moya.

Peor aún: Muchas startups queman todo el capital que han levantado en un único MVP. Así que después de ir y ver que pasa, si los resultados no son tremendamente positivos, la startup muere de inanición.

¿Y cómo evitamos este problema? 

Obviamente no hay una fórmula única y segura, pero sí varias técnicas y enfoques que ayudan:

Lean UX. Nuestro enfoque práctico a la experiencia de usuario ha tenido resultados fabulosos con nuestros clientes (y nos ha llevado a conferencias a mostrar nuestra metodología). Al fin y al cabo, si el MVP es un medio para validar suposiciones y a veces un MVP es relativamente caro, cabe preguntarse qué otros medios hay. Lean UX trae las técnicas de la disciplina de la experiencia de usuario para testear y prototipar barato y validar (y muchas veces clarificar y explicitar) las hipótesis y suposiciones sin tener que hacer un diseño gráfico acabado o escribir cientos o miles de líneas de código. No me voy a expandir mas sobre este tema, pero puedes saber más acá y acá. (¿Interesado en ver esto aplicado a tu startup? ¡Contáctanos!)

Un roadmap de aprendizaje, no de features. Recuerda: Tu startup en su frase temprana tiene como objetivo validar y aprender lo que nadie (o muy pocos) ha validado o aprendido antes, en lugar de ir e implementar todos los features que has visto en la competencia o los referentes de tu startup.

Por ejemplo, Zappos (venta de zapatos online, vendido a Amazon por mil millones de dólares) no partió emulando todas las características de una tienda online. Ellos simplemente fotografiaron zapatos de la tienda física mas cercana, pegaron las fotos en una web (sin carro de compra ni nada) y validaron si alguien estaba dispuesto a comprar zapatos. Una vez que efectivamente había gente que compraba zapatos (y el fundador de Zappos tenía que ir a comprar personalmente dichos zapatos a la tienda y enviarlos por correo al comprador) empezaron a construir un sitio web decente.

¿La lección? No te preocupes de cómo tu MVP va a validar sus hipótesis. Preocúpate más bien de qué hipótesis y suposiciones quieres validar primero.

Normalmente, eso lleva a pensar más en qué cosas pueden echar abajo toda la idea (ej: si la hipótesis de que “la gente comprará zapatos sin probárselos primero” falla, no tiene sentido hacer mucho más). Ordenar las hipótesis de tu startup por orden de prioridad es un ejercicio iluminador.

Y además, nos permite a empresas como Continuum ayudarte mejor. Podemos ver cómo construir de la forma mas barata y rápida posible las cosas claves que ayudarán a despejarte el camino en el bosque de las hipótesis a validar, en lugar de desarrollos interminables que duran muchos meses. Podemos tomar las decisiones correctas cuando haya que decidir entre hacer algo híper robusto o híper flexible. Podemos incluir mejores analíticas desde el principio, en lugar de perderse en la maraña de datos (muchas veces mudos) de Google Analytics.

Así podemos ayudarte a tener usuarios, ingresos y levantar inversiones, y no sólo quedarnos en diseñar y construir software.

¿Y por qué debiera creerles? 

Porque aprendimos esta lección en la práctica. Por allí por el 2010, y con la mejor de las intenciones, empezamos a trabajar con startups haciéndolo como mejor sabíamos. Para ser sinceros, compartimos las culpas con algunas startups en no encontrar la manera correcta de descubrir conocimiento válidado y también más de una vez optamos por el “construir y ver qué pasa”.

Nos gusta y nos enorgullece construir productos muy sólidos técnicamente, elegantes, bien hechos, bien testeados, bien diseñados, atractivos. Pero no nos conformamos con hacer bien la pega técnica y estética.

También queremos que los productos que hacemos tengan montones de usuarios felices y productivos. Por eso nos cuestionamos constantemente la forma en que hacemos las cosas, las tratamos de mejorar, aplicamos y compartimos lo que aprendemos.

¡Pero tampoco obligamos a nadie a seguirnos! :)

Continuum on tour

(Manténte informado en el sitio del tour o a través de nuestro twitter)

En el corazón de Continuum está enseñar lo que sabemos o aprendemos, por eso desde el 2009 creamos los L&B (Lecture & Beer & Beef, charlas de viernes con cervezas y asado), en ese mismo año comenzamos con los meetups de lenguajes dinámicos, hemos estado presente con charlas en varias conferencias como las “Jornadas regionales de software libre“, “AgileDay“, “ágiles 2013″, “Encuentros Linux“, “RubyConf“, “UXMad” o “Google Summer of code“.

Además en el 2011 así como este 2013 co-organizamos la StarTechConf (a realizarse los días 25 y 26 de Octubre) .

continuum-on-tour

Como si todo esto fuera poco ahora por iniciativa de los chicos en la oficina liderados por Ricardo Jara se creó “Continuum on tour” donde en esta primera edición y durante dos días un equipo de Continuum más algunos amigos darán charlas en diferentes universidades del país para enseñar a los futuros techies (y también quienes estén cerca) sobre motivación, lenguajes de programación, gestión de proyectos, experiencia de usuario (UX), diseño, desarrollo front, desarrollo de aplicaciones móviles, emprendimiento y liderazgo.

Si estás o vives en algunas de las ciudades que los próximos Jueves 29 y Viernes 30 de Agosto visitaremos no te pierdas esta magnifica oportunidad de venir a aprender y compartir con nosotros, no cuesta nada.

Manténte informado en el sitio del tour o a través de nuestro twitter.

 

“¿Deberían los Diseñadores Escribir Código?” es la pregunta incorrecta

El dilema de si los diseñadores deben conocer y escribir el código sobre el cual trabajan no es reciente, y hay bastaaaaante discusión al respecto. Desde que nació la idea del “diseño Web”, o desde la primera vez que a un diseñador se le ocurrió saltarse FrontPage o Dreamweaver y meterse directo al código, que el debate sobre si los conocimientos de programación deberían formar o no parte de las competencias del diseñador moderno no se ha apagado. Lejos de eso, en una era de Bootstraps y Boilerplates y front-enders, hoy es más complejo que nunca saber dónde se traza la línea.

Intentando simplificar, las opiniones al respecto se polarizan en dos:

  • Quienes opinan que los diseñadores NO deberían escribir código, porque no forma parte del mindset de un diseñador, porque en sí mismo es todo un mundo que debe ser aprendido con dedicación, y porque cada segundo ocupado en (intentar) programar es un segundo perdido en hacer lo que sí saben: diseñar. Asimismo, el diseñador que se “queda pegado” en saber código se pierde de tener una mirada más global y estratégica de lo que implica la creación de un producto (hoy conocida como UX). O sea: pastelero a tus pasteles.
  • Quienes opinan que los diseñadores SÍ deberían escribir código, tanto porque deben conocer su soporte, para ser capaces de entender la estructura y las limitaciones del medio en el cual diseñan, porque hoy se esperan profesionales capaces de hacer el end-to-end, y porque finalmente el dominio de la interfaz de usuario necesita combinar ambas variables: tanto la parte visual/artística/conductual, como la variable tecnológica y de las posibilidades y limitaciones de la plataforma.

Como diseñador y estratega UX que además ama escribir código, considero que la pregunta está planteada de una forma que nunca llevará a una respuesta útil. ¿Por qué?

  • En primer lugar, ¿qué código? ¿Estamos hablando de HTML/CSS/JS, o estamos hablando de una aplicación Python full-stack? ¿Y hablando de JavaScript, nos basta con saber configurar plugins de jQuery, o estamos hablando de poder escribir aplicaciones en Backbone.js?  Si un diseñador debe diseñar una aplicación móvil, ¿debería saber escribir Objective-C? Por “código” podemos entender una infinidad de lenguajes con finalidades muy distintas.
  • ¿La pregunta implica que un diseñador debe escribir código MIENTRAS diseña? Hay un momento para diseñar/planificar/estructurar y otro para escribir código. ¿Debería un diseñador escribir código… en Photoshop? ¿En la pizarra? ¿Mientras prototipa? ¿Usando su tableta gráfica? La pregunta es confusa. La fase en la que ideas visuales, patrones de interfaz y objetivos de negocio se combinan para generar lo que llamamos “diseño” es una etapa muy distinta a la etapa de producción, donde alguien (el desarrollador) se sienta a implementar lo planificado. Esto es cierto incluso para entornos Ágiles; la única diferencia es que el proceso se lleva a un nivel microscópico.

Por eso es que planteo que la pregunta correcta es: ¿En qué momento y hasta qué nivel deberían los diseñadores involucrarse en el código?

Esta pregunta tiene varias implicancias:

  • “Involucrarse en el código”, y no necesariamente escribirlo. Un diseñador eficiente y serio entiende las limitaciones y las posibilidades que le ofrece la plataforma. Por eso un diseñador editorial aprende de técnicas de impresión y papeles. Pero esto no implica ser el encargado de producir el código final; la razón puede ser meramente el tiempo, o contar con un desarrollador front-end con más proficiencia. Dicho esto, el código no puede ser entendido en abstracto; se requiere que el diseñador se haya metido bajo el capó a mirar el motor y entender cómo funciona, aunque no sea un mecánico experto.
  • Involucrarse en el código implica entender cómo se estructura, cómo funciona y cómo responde. Entender conceptos como el DOM o la estructura jerárquica de HTML, o los fundamentos del diseño responsivo, sólo por dar ejemplos, no requiere escribir código, pero sí exige una cuota respetable de estudio y de práctica en terreno.
  • Dejo aparte el uso de los editores WYSIWYG (como Dreamweaver), dado que crean una capa de abstracción entre el diseñador y su soporte. En un editor WYSIWYG el diseñador continúa pensando de manera similar a como se diseña un afiche, por lo que no existe realmente una adaptación mental a las particularidades de una aplicación Web o móvil.
  • “En qué momento” asume que hay un momento en el que los diseñadores deben involucrarse en el código. El proceso de diseño, en general, involucra más pensamiento visual, creativo e investigativo que producción de código; sin embargo, en la fase de testeo con usuarios (por dar un ejemplo), muchas veces el conocimiento de tecnologías Web y frameworks permite construir prototipos más realistas y por ende con resultados más confiables. ¿Será este código luego reutilizado en producción? Tal vez no, y no tiene nada de malo. Pero le corresponde al diseñador entender y decidir en qué situaciones debe cerrar el Fireworks y abrir el editor de texto para lograr un mejor diseño.
  • “Hasta qué nivel” depende de las capacidades y gustos del diseñador y del equipo de trabajo. Si el equipo es pequeño, tal vez el diseñador tenga que además hacerlas de front-end. Si en el equipo hay desarrolladores front-end dedicados y expertos, la labor del diseñador puede caer más en la coordinación y en asegurarse que el comportamiento del producto real corresponde a lo que se diseñó. A veces las limitaciones de tiempo hacen que el mismo diseñador tenga que estar presente en varios proyectos y delegar la parte front-end a otra persona que hará más rápido el trabajo. Y, por cierto, al diseñador tiene que gustarle meterse en el código.

En lo que he podido observar, tanto en Continuum como en otros lugares, no hay duda: un(a) diseñador(a) que entiende código y es capaz de ayudar a implementar lo que diseña siempre tendrá una ventaja por sobre quien no lo hace. Diseña con más soltura, sus soluciones no generan cuellos de botella, es posible darle más autonomía y en muchos casos ahorra tiempo, diseñando directamente en el navegador, donde las papas queman. Este conocimiento de primera fuente no se puede fingir, y es fácil distinguir a quien diseña entendiendo lo que pasa debajo de quien simplemente imita modos y patrones existentes.

Pero claro: hay momentos y momentos para meterse a escribir código, y dado que el “diseñador-lobo-estepario” (que trabaja solo y encerrado) está en retirada, saber ceder la posta a veces puede ser más beneficioso para el equipo que tratar de correr la carrera completa por sí solo.

Update: Hay quienes apuntan que “programar” y “escribir código” son cosas distintas. Más allá de la definición apegada al diccionario, es un hecho que ambos términos han sido usados indistintamente al debatir. La ambigüedad del término es precisamente la que señalo en el punto titulado “¿Qué código?”. Eventualmente un diseñador que escribe código podría terminar programando.

Impresiones de UXMad 2013

El pasado 12 y 13 de julio se realizó en Madison, Wisconsin (EEUU) la conferencia UXMad, que juntó a entusiastas y profesionales de la UX en torno a una serie de charlas relativas a diseño, experiencia de usuario, agilidad e innovación. Tuve el honor de ser invitado como charlista a presentar, con algunas novedades, la metodología de Lean UX en base a minientregables con la que trabajamos en Continuum para crear productos centrados en el usuario.

Madison

La conferencia juntó a notables de la experiencia de usuario, como Russ Unger, autor de A Project Guide for UX Design, Hampton Catlin, creador de HAML y SASS, o Jenn Downs, de MailChimp, por nombrar sólo algunos.

El Overture Center for the Arts, sitio de la conferencia

Algunas ideas interesantes que recogí de las charlas:

  • Russ Unger (que presentó el trabajo de Jim Henson, el creador de los Muppets como ejemplo para la UX): Prototipa mucho. Mejora la historia y el producto a lo largo del tiempo. Las buenas experiencias son invisibles, sólo nosotros sabemos lo que pasa “tras bambalinas”.
  • Hampton Catlin: La interfaz es el producto. Los usuarios jamás ven lo que los devs ven. Es hora de darle un upgrade al desarrollo front-end y dejar de considerarlo el “hermano chico”, dado que es en el front-end donde se produce la mayoría de la experiencia de usuario.
  • Jenn Downs (que mostró ejemplos increíblemente creepy de empresas tratando de automatizar la coloquialidad con sus usuarios): No puedes automatizar la empatía con tus usuarios. No finjas que los conoces sólo basado en un par de datos o un comportamiento de compra. No programes tweets. Y por favor, no le repitas el mismo tweet a distinta gente.
  • Luego seguí yo. A la presentación de Lean UX que varios conocen le añadí un concepto nuevo, The Validation Onion. Aquí están las slides actualizadas.
  • Martin Atkins (que dio una performance increíblemente divertida y procaz sobre los detalles sabrosos de ganarse un Kickstarter): Fucks. Lots of fucks. Ojo con lo que prometes a la gente que te pone plata. Y no temas lanzarle muffins de mora a la audiencia (realmente lo hizo).
  • Abby Fox y Sullivan Sweet (estudiantes de secundaria que participaron en la LEGO League) hablaron de lo que significó repensar la manera en la que la gente lleva sus loncheras y ice packs para prevenir la formación de bacterias. Muy emotivo por lo jóvenes y preocupados por la innovación que son estos chicos.
  • Carl Smith: Conserva el control sobre tu dinero. Evita levantar plata porque sí. Bootstrapéate. Evita los acquihires. Una vez que aceptas inversionistas, ellos se vuelven los dueños de tu idea y de tu tiempo, así que escoge tus batallas.
  • Andrew Maier: Diseña para educar a tus usuarios. Enseña a través de la interfaz y el diseño. Preocúpate de la cognición.
  • Bermon Painter: No más wireframes clásicos (con lo que no podría estar más de acuerdo). Si se trata de prototipar, parte con sketches o bocetos rápidos en papel o pizarra, y luego salta a prototipar en el navegador (design in the browser) lo antes posible. Aprende a prototipar con agilidad.
  • Riley Graham (que presentó técnicas y métodos para Agile UX): Usa retrospectivas, pairing y just-in-time para trabajar codo a codo con los desarrolladores al momento de producir diseño e interfaces.
  • Moldover experimenta creando sus propios instrumentos electrónicos e interfaces musicales con Arduino y modificando una guitarra eléctrica, en un curioso crossover con una guitarra de Guitar Hero (la Robocaster, como la llamó). Aquí algo de lo que estuvo demostrando.
  • Pamela Pavliscak: Por qué la UX necesita números. Las historias se cuentan mejor con números. Ve más allá de recolectar un par de datos anecdóticos y busca recoger métricas que realmente te permitan entender mejor a tus usuarios. El problema es que la UX suele tomar decisiones basándose en demasiadas adivinanzas y pocos datos que la respalden.
  • Cat Smith: Toda la experiencia de usuario y de cliente está en la subjetividad del espectador. Basta una cara triste para que toda tu empresa se vea como unos pelotudos. Es muy fácil arruinar la experiencia. Cuida todos los detalles.

Para más fotos y detalles, revisa mis tweets del 12 y 13 de julio. Un gran agradecimiento a Jim “Big Tiger” Remsik y a Jen Remsik, que hicieron posible una conferencia increíble. Y nuevamente, fue un honor haber podido participar.

¡Hasta la próxima!

 

Notes from Lean UX workshop at The LAB

Here are the notes taken by David Notik (@DaveNotik) of the Workshop given by Sergio Nouvel, our UX consultant at The LAB Miami. We wanted to share them here because they provide an excellent summary of what we could share on these meetings:

Session 1

Session 2

On July 12 and 13, Sergio will atend UX Mad and will speak there on Friday. Stay tuned for our full coverage!

Workshop Lean UX de Continuum en Miami

Continuum está abriendo oficinas en Miami y en Lima, y la idea en cada lugar es hacer lo mismo que hacemos en Chile: conectarnos con los eco-sistemas de emprendimiento e innovación de cada lugar, intercambiar ideas y regalar conocimiento. Es por eso que mañana estaremos organizando workshops gratuitos de Lean UX en LABMiami, un centro de co-working en la efervescente zona de Wynwood:

flyer-lean-ux-workshop

Si andas por Miami, únete a nosotros.

¡Nos vemos!

Entrevista a Sergio Nouvel acerca de Lean UX

Antonio Ognio entrevistó ayer a Sergio Nouvel, nuestro experto UX, para el sitio peruano lamula.pe. Conversaron acerca de las bases de Lean UX y cómo esta metodología ha ayudado a startups y proyectos digitales de gran envergadura.

Como complemento, te recomendamos chequear además la presentación de Lean UX de Sergio aquí.

 

La verdadera meta

La gente que practicaba las metodologías de cascada estaban, en su momento, buscando metas muy locales. Por ejemplo: Especificaciones rigurosas, largas, detalladas y no ambiguas eran un resultado buscado para gente mal de la cabeza que quería hacer un gran diseño antes que nada. Un completo plan de pruebas manuales era tambien una meta valorada para ellos. Como muchas otras metas locales.

El movimiento ágil finalmente desafió esas tonteras y buscó el software que funciona, la colaboración, responder al cambio, interacciones e individuos.

Excepto que software que funciona también es una meta local. Necesitas que la gente use el software. Software que funciona pero sin usuarios es, bueno, bien inútil (¡y triste!):

“I was a devotee of the latest in software development methods (known collectively as agile development) which promised to help drive waste out of product development. However, despite that. I had commited the biggest waste of all: building a product that our customers refused to use. That was really depressing.”

- Eric Ries, “The Lean Startup”

Software que funciona con usuarios de verdad también es un tipo de meta intermedia. He visto software en uso por usuarios reales quienes sólo están siendo estorbados por tal software. Las empresas grandes (“enterprises”) son bastantes buenas en comprar aquellas piezas de software improductivo (aunque funcional) y sus empleados usualmente se convierten en desafortunadas víctimas usuarios.

Untitled-2

La verdadera meta que siempre debieramos buscar es software que funciona, tiene usuarios y les genera beneficio de alguna forma. Software que haga a las personas productivas. Software que haga que las personas pasen un buen rato. Software que haga que las personas sonrían.

Lo que sea que puedan modificar y probar para llegar allí debiera ser probado. Nada, ni siquiera las llamadas mejores prácticas debieran ser sagradas e intocables en el camino a la meta real.

Software que ayude a las personas. Esa es la meta que buscamos.