No quiero ser pesimista, pero digo que me da pudor porque, cuando he andado por la ciudad, no son pocos los locales comerciales de distinta índole que se ven vacíos, cuando no, sencillamente abandonados. Restaurantes, peluquerías, tiendas de diversos rubros cerradas. Proyectos fracasados que implican personas sin trabajo, y hablamos de mucha gente y familias sin ingresos. Y sí, entonces me siento afortunado y agradecido. No sé si hay espacio en este contexto para sentirse orgulloso. Dicho está, más bien me da pudor.

Reconocimiento a nuestra labor

Que no se me mal entienda, uno siente orgullo por el proyecto de empresa que ya lleva 10 años, por las personas que conforman el equipo, por el trabajo realizado que siempre persigue la excelencia. Uno siente orgullo cuando el cliente te felicita por la calidad y el esfuerzo entregado en pos de sus objetivos; uno siente orgullo cuando algún compañero de trabajo más novato te dice “me sacaste el jugo; no lo creía, pero lo logré”, cuando en medio del tedio de la rutina uno se exige a sí mismo y a los pares el 1001%. 

Sí, ese orgullo se siente a diario. Sin embargo, no queda en el olvido aquella frustración cuando un integrante del equipo no está alineado ni comprometido con ese nivel de exigencia, de auto exigencia, en el que uno se juega la vida como Sherazade, por si la metáfora del infinito no le quedó clara al incauto lector. 

Un triste dolor

Pero no es del orgullo de lo que quería hablar, sino del pudor de sentirse afortunado, de haber estado en medio de esta pandemia en un rubro que se hizo casi imprescindible, con unos saberes y unas experiencias que transformaron a estas empresas en apetecibles, en deseables compañeras de viaje –utilizando, esta vez, la metáfora del viaje de IDA sí conocida por el incauto lector. 

Pudor porque el amigo o el primo lleva 9 meses sin trabajo y las perspectivas de futuro no son del todo alentadoras; pudor porque estamos dentro del pequeño porcentaje de los privilegiados en una metrópolis como cualquiera que depende del crecimiento económico devorador de recursos y, no de una economía sustentable y respetuosa del medio ambiente. Estas situaciones nos hacen creer que este año quedará en el olvido, por parte de muchos. 

Un año de aprendizajes 

En el otro extremo, el conspicuo lector se preguntará por qué hablar del pudor y podrá hasta emocionarse pensando en la desdicha de millares y en la fortuna de unos cuantos privilegiados. A ese lector le digo que fue un poco de suerte, aunque también han habido 10 años de “crear valor” en los detalles. Este lector entenderá muy bien otra metáfora, esta vez, con arraigo en la Historia: Colón descubrió América, no la creó. 

Asimismo le digo que no todo ha sido acertar, también ha habido mucho de errar. Me atrevo a decir que han habido más errores que aciertos, pero los hemos transformado en oportunidades. 

Con el prisma que me toca mirar hoy los acontecimientos, los errores nos han hecho madurar, los aciertos crecer y la humildad prevalecer. La post verdad, así podríamos llamarle hoy a juzgar los errores del pasado con los ojos del presente, cobijados bajo las sensaciones que nos provoca el día a día de este año para el olvido.

Difícil pero no imposible

Quiero decir, que cada día tiene su afán, que pese a todo estamos bien, que ha habido algo de suerte pero mucho más de esfuerzo, que gracias por todo a todos, pero que cuidado que la ola te bota porque la competencia es brava y el humo es abundante y atractivo en sus multicolores cinemáticos. Ni en la cima ni la sima estamos a salvo del microbio ni del virus maldito, hemos tenido suerte, pero la suerte es cambiante e ingrata y necesitas algo más que los laureles del pasado para mantenerte vigente o, dicho en negativo, para no desaparecer del mapa.

Nuestra más fiera competencia podrá sentirse hoy en éxtasis por sus números y ventas, podrá ayer habernos decretado inviables, e incluso podrá superarnos en la tecnocracia ingenieril del empleo, pero no nos quitará jamás el alma: ñoños de la UX, ni en fiestas ni mercenarios.

The post Un año para el olvido, pero no appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

Ciertamente la lista de integraciones disponibles y que podemos usar de manera cotidiana es larga y, como usuarios, no tenemos que saber que todas esas integraciones son gracias a las APIs. De hecho, ni siquiera tenemos que saber qué es una API, ni tampoco saber cómo programar una. Sencillamente, transitamos entre redes de forma rápida gracias a ellas.

Las APIs están ahí y nos pueden ayudar en mucho más

Probablemente en alguna reunión de trabajo los informáticos de T.I. han hablado de solucionar algún requerimiento con una API. Cuando esto sucedió, seguramente entendimos poco de lo que han dicho, aunque parecía ser la solución más sencilla y práctica. Al hacerlo, todos han quedado satisfechos, pero nadie sabe a ciencia cierta qué hará T.I., ni cuánto demorará.

En este contexto, es importante saber algunas cosas mínimas sobre las APIs. Saber, por ejemplo, qué es un método y un endpoint; diferenciar entre XML y JSON, o entender que cuando hablamos de método y función, nos referimos prácticamente a lo mismo. Estos conocimientos mínimos nos ayudarán a definir mejor el alcance de nuestro requerimiento y a estimar de mejor forma tiempos y presupuestos, sin minimizar ni sobredimensionar, los esfuerzos.

Entonces qué es un API

De manera simple, podemos decir que es un protocolo que, mediante un lenguaje común, permite intercambiar información y ejecutar tareas remotas entre dos plataformas distintas, programadas en lenguajes diferentes.

Este protocolo determina tres cosas:

1. La información que se recibe, bajo qué método y formato.
2. Qué rutina, tarea o función se ejecuta, es decir, qué hará con la información recibida.
3. Cuál será la respuesta que recibirá una vez ejecutada la tarea. En qué formato y estructura nos entregará los datos resultantes de una tarea ejecutada correctamente o nos dirá si hubo un error.

Existen varios protocolos o especificaciones. Los más populares hoy son SOAP y RESTful, aunque en los últimos años GraphQL ha ido ganando cada vez más adeptos.

Si trabajamos con SOAP entendemos que el lenguaje común para intercambiar información será XML y que se usará un documento XML especial, llamado WSDL. El cual describe tanto los métodos -rutinas o funciones- del servicio, como los parámetros que recibe y devuelve cada método.

Si trabajamos con REST, en cambio, sabemos que utilizaremos mayoritariamente JSON para intercambiar información. Además, usaremos cabeceras POST, PUT, UPDATE y DELETE para informar un cambio de estado. También, utilizaremos peticiones GET con Query Strings para conseguir datos y que será imprescindible (a falta de un WSDL) una documentación para conocer las URLs de cada uno de los endpoint correspondientes a cada una de las funciones que necesitamos ejecutar. Así como la descripción de cada parámetro que recibe y devuelve esos endpoint.

Una API ¿Es la mejor solución?

Es probable que con el correr de las semanas y de los meses, aparezcan algunos problemas en su implementación. Por ejemplo, si quienes consumen la API no son los mismos desarrolladores que la construyeron, no cuesta mucho imaginar que los primeros no puedan seguir avanzando, porque la API no está terminada y porque los desarrolladores no han documentado nada de lo que han hecho.

Una API pequeña, que cumple una sola función, puede ser algo simple y rápido de construir; pero una API que dispone de múltiples endpoints y que expone -por decirlo de algún modo-, muchas de las funciones complejas de una plataforma, puede tardar bastante más en desarrollarse.

Depende de la función

Resulta que en una API extensa, muchas de sus funciones están interconectadas y cumplen con algo más que los requisitos mínimos de seguridad. Además, cada uno de los endpoints deberá ser testeado según los múltiples casos de usos que se plantearon en la definición de alcances. Así, cualquier desarrollador puede usarla, mientras que en paralelo se ha ido documentando debidamente cada uno de los métodos programados.

Para que no quepan dudas, se debe programar, testear y documentar prácticamente a la par. Y no hay que olvidar que se deben cumplir ciertos alcances mínimos, o ciertos casos de uso, que por obvios que parezcan al sentido común, no necesariamente los son para un programador que se guía por documentos con definiciones de alcances precisas y detalladas.

Vemos un ejemplo. El requerimiento es que necesitamos conectar un formulario de contacto en el sitio web con un CRM propietario. El sitio está en WordPress en un servidor de Amazon y el CRM, en un servidor montado en una LAN de T.I. En el sitio web, el formulario tiene cuatro campos: nombre, email, tema y mensaje, donde el campo tema es un selector con las opciones sugerencia, reclamo y felicitaciones.

Cuando lo sencillo se complica

En principio, pareciera ser todo muy sencillo, pero resulta que el desarrollador a cargo de levantar el API decidió innovar un poco y el endpoint que programó recibe en el body un JSON de 6 parámetros: name, email, subject, message, status y token. En este caso, el subject acepta valores integrales (1, 2, 3); status acepta un booleano y el campo name solo acepta un strings de máximo 15 caracteres.

De un momento a otro, aparece un lenguaje técnico con el que hay que familiarizarse rápidamente para comprender y verificar si se están satisfaciendo los alcances definidos para esta API y si las estimaciones iniciales de esfuerzos sufrirán variaciones significativas.

Es cierto que la jerga técnica hace que todo se perciba como más complejo, pero es necesario superar esa barrera para -en jerga deportiva- poner la pelota sobre el césped y dejar las piruetas de lado. En este punto la documentación es clave.

Saber documentar y crear en base a los alcances del proyecto planteado, es fundamental. Para ello, tener claro las responsabilidades del equipo, ayudará a cumplir sus objetivos. Desde la experiencia, podemos decir que esas responsabilidades se dividen entre mandante o gerencia y T.I. y deben preocuparse de:

– Ejecutivos / Mandante / Gerencia: Entender lenguajes de programación básicos o conceptos utilizados en el desarrollo para estar informado sobre cómo se construirá el proyecto y alinearlo con los alcances establecidos.

– TI / Equipos de desarrollo: crear, documentar y testear las herramientas construidas, con énfasis en registrar lo desarrollado y sus posibles alcances.

Lo mínimo de una documentación para un API

Si no hay documentación, los problemas que tendrá el desarrollador que está haciendo la integración con CRM serán varios.

Problemas comunes de la ausencia de documentación

– Qué tipo de API se está usando

1. Si es SOAP cuál es la URL del WSDL y cuál es el método a usar.
2. Si es RESTful cuál es la URL del endpoint

– ¿Cómo entregar los parámetros? ¿En un JSON o XML, por POST, PUT o con GET y query strings?

Luego, al despejar estas dudas iniciales, seguirán:

1. El formulario envía los campos nombre, email, tema y mensaje pero no se guarda nada en CRM.
2. ¿Se necesita un token?
   • ¿Cómo se obtiene o genera el token?.
   • Cada cuánto tiempo se requiere validarlo.
3. Todos los contactos quedan con subject 1 o “sugerencia”.
4. Todos los contactos quedan con status false y en el CRM quedan en la papelera.
5. Hay contactos que nos se guardan o quedan, en el mejor de los casos, sin nombre.

Sin documentación no hay integración

Todos estos problemas evidencian que la documentación es tan o más importante que  la programación misma del API. Sin documentación prácticamente no hay integración posible. En nuestro ejemplo el desarrollador no ha sido informado de los elementos esenciales para hacer su trabajo:

1. ¿Se usará uno o varios endpoints?
2. ¿Cuáles son las URLs de los endpoints?
3. ¿Qué tipo de API que usará? y, en consecuencia, ¿cuál es el formato para intercambiar información?
4. ¿Cuál es la descripción y detalle de los campos que necesita enviar al API?
5. ¿Qué descripción y detalle de campos recibirá de vuelta del API?

En ese contexto, la documentación requerida es sencilla, pero imprescindible. Bastaría con algo como lo que sigue:

Pero eso no es todo, luego viene el problema de que en el formulario hay cuatro campos con nombres en español y el CRM necesita 6 con nombres en inglés para funcionar.

Mientras el desarrollador que integra no conozca ese detalle, no tendrá forma de adivinar. En este caso la forma de documentar también es sencilla, se debe indicar por cada parámetro, el tipo, extensión mínima y máxima, si es obligatorio y si se necesita usar otro endpoint para conseguir o formatear un dato.

Con esta tabla simple el integrador vería de manera rápida y sencilla qué hacer para hacer funcionar la integración, tiene que resolver aún algunos problemas:

1. Cambiar los nombres de los campos a los requeridos por el CRM.
2. Limitar a 15 caracteres el campo nombre, dado que en CRM no se guardarán aquellos que excedan esa extensión.
3. Para el tema o subject necesita una tabla de conversión.
4. Enviar un valor booleano para status (0 ó 1)
5. Y conseguir un token en el método obtener_token

Todos estos puntos deberían venir igualmente documentados, por ejemplo:

Tabla de conversión para valores de subject.

Este caso aparentemente es de una obviedad y sentido común casi exagerado, pero la verdad es que no es así. Los valores 1, 2 y 3 son absolutamente arbitrarios, bien pueden ser 100, 200 y 300 o tener una asociación distinta. Además, si el integrador ignora que debe entregar un integral en vez de un string, existe una alta posibilidad de que el string sea siempre interpretado como 1.

En el caso del token la documentación es similar. Se indica el endpoint, el método de acceso (que en REST es distinto al concepto método de función) y los parámetros de entrada y salida.

Token

Parámetros GET

ID de clientes en ambientes Dev y Prod

cliente_id ambiente desarrollo: 1111222233334444
cliente_id ambiente producción: 4598357495464685

Detalle de respuesta JSON

Finalmente el último problema por dilucidar y que no resiste mucho análisis, es que los posibles casos de uso para ingresar nombres con extensiones mayores a 15 caracteres son probablemente mayoritarios. En tal caso, solucionar esto depende de una corrección que deberá realizarse en el CRM y no en la integración ni en el formulario mismo.

Algo similar debiese ocurrir con el campo status, que desde el punto de vista del sitio web, claramente se puede omitir por cuanto obedece a una lógica interna del CRM y no es vinculante con el sitio.

Conocimiento es poder

En la práctica, conocer cuál es el objetivo de implementar una API en un proyecto, y saber en detalle, de qué forma fue ejecutada, nos beneficiará enormemente. Desde la optimización de tiempos, a la prevención de errores y por supuesto, su correcto funcionamiento.

Antes de utilizarlas, definitivamente debemos conocerlas.

The post Web APIs: ¿Por qué debemos conocerlas? appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

Nos llenamos de APIs

A diario usamos Slack, Google Suite, Jira y una larga lista de aplicaciones web que se comunican entre sí. Constantemente, casi sin reflexionar, otorgamos autorizaciones a cuanta “aplicación” nos solicita permisos para acceder a nuestros datos; con la promesa de que obtendremos una mejor experiencia de uso. Uber, Waze y Spotify, por mencionar ejemplos cercanos a todos, nos facilitan y personalizan la experiencia si las integramos con Google o Facebook.

Al cabo de unos pocos años pasamos de aplicaciones monolíticas de escritorio -que prometían hacerlo casi todo- a plataformas web fragmentadas en cientos de pequeñas integraciones de servicios. Hoy la tendencia en programación es la de construir micro servicios que se van integrando para construir herramientas más potentes y versátiles. 

Y más aún, sin darnos cuenta, las APIs se tomaron un espacio que no para de crecer, llegando, por ejemplo, a nuestros hogares con Google Home o Amazon Echo. Herramientas que nos permiten conectar una variada gama de “smartthings”, las que van desde ampolletas y parlantes hasta electrodomésticos como estufas y aspiradoras. Hoy todo es “conectable” y lo podemos controlar con nuestro teléfono o con un simple “Ok Google”.

En ese contexto, nos llenamos de APIs. No las vemos pero están ahí, con lo positivo y negativo que ello trae. Nuestros datos circulan por la red, podríamos decir que nos siguen para facilitarnos las cosas, permitiéndonos identificarnos y personalizar con poco esfuerzo una aplicación. 

Por ejemplo, hace un par de semanas migré en dos click mi colección de música desde Google Play Music (QEPD) a Youtube Music. Eso incluyó todo mi historial y el resultado es que hoy las sugerencias de artistas y playlist son mucho más asertivas. 

La promesa de la seguridad

En este uso, hay riesgos que no debemos ignorar, como la publicidad hipersegmentada de Facebook y el escándalo de Cambridge Analytica. Nuestros datos y actividades en Internet convergen sobre unas pocas grandes plataformas que conocen hasta la hora en que apagamos la luz o pasamos la aspiradora.

Particularmente en IDA no solo nos toca usar APIs de forma intensiva, sino que también nos ha tocado desarrollar para integrar distintas plataformas. Como indicaba más arriba, la tendencia hoy en programación y en SRE es construir o levantar micro servicios, que en muchos casos  podemos entender como pequeñas APIs de usos muy específicos y que se van combinando en plataformas para construir herramientas con utilidades más amplias. Slack y Jira son casos muy representativos de este tipo de plataformas. 

Más beneficios

Son varias las ventajas de construir aplicaciones o plataformas basadas en una Arquitectura Orientada a Servicios (SOA); las principales son modularidad, escalabilidad, flexibilidad, agilidad, versatilidad y entrega continua. 

Sin querer entrar en el detalle de cada una, destaco la modularidad y la escalabilidad, por cuanto implican robustez y redundancia. Es decir, a diferencia de una aplicación monolítica, si un componente o servicio falla, la aplicación podrá seguir funcionando, primero, porque el servicio caído no afecta el funcionamiento de los otros y, segundo, porque se puede reparar y reponer más rápidamente que en un sistema monolítico, que falla completamente al producirse un error en alguno de sus componentes. 

Por otra parte, al tener la capacidad de incorporar servicios descentralizadamente, se convierten en herramientas más versátiles y atractivas para sus usuarios, incorporando nuevas capacidades mediante verdaderos marketplaces, donde puedo testear y comparar una misma funcionalidad implementada por dos proveedores distintos. Lo que nos permite quedarnos con aquella implementación que ofrezca mejores atributos.

¿Cuánto las necesitamos?

En esta realidad llena de APIs y servicios es altamente probable que tengamos que enfrentar constantemente la situación de evaluar si nuestro negocio o sitio requiere verdaderamente integrarse con algún proveedor de servicios. En muchos casos, no tendremos alternativas y en ese contexto necesitamos saber a qué nos enfrentamos. 

La figura del iceberg sirve perfecto para ejemplificar que los usuarios solo aprecian la facilidad de usar una API, pero bajo eso hay un gran volumen de definiciones, protocolos, información y formatos que deben ser abordados para que esta “facilidad de uso” se logre. 

¿Necesitamos un API realmente?

APIs como un puente 

Partamos por verbalizar que API significa “Interfaz de Programación de Aplicaciones”. Sin entrar a detallar todos los aspectos técnicos es suficiente explicarla como un “puente” que permite la comunicación entre dos plataformas, aplicaciones o programas y entender que “este puente” define un protocolo o un estándar sobre cómo traspasar información entre un programa y otro. Es decir, qué y cómo se envía un conjunto de datos, qué esperamos que se haga con ellos y qué respuesta tendremos de vuelta.

Quienes estamos relacionados con proyectos digitales hemos visto en las API la solución a muchos de nuestros problemas, pero no a todos. Por lo tanto, siempre es importante verificar si existe una necesidad real de usarlas, y para eso, compartimos estos siete puntos que pueden orientar en esta verificación.

Verifica estos puntos

Facilita el acceso 

¿Aumentan significativamente los usuarios que podrán acceder a mi servicio o sitio simplificando el proceso de autenticación y registro de cuentas?

¿Cuál es la relación de tiempo, esfuerzo y costo para el desarrollo de esta integración?

Ampliar posibilidades funcionales 

¿Agregar nuevos servicios que mejoran la experiencia de tus usuarios o son funcionalidades accesorias y de bajo impacto? ¿Tienes métricas que demuestren la necesidad de los usuarios para estas funcionalidades? O ¿Es un requerimiento levantado desde la gerencia sin argumentos fundamentados en test de usabilidad, encuestas o estudios de usuarios?

Centralizar información  

¿Necesito alimentar una plataforma con muchas fuentes de datos? ¿El volumen de datos es significativamente alto para trabajarlos de forma descentralizada? ¿Necesito analizar y comparar de manera integrada estos datos?

Transformar datos en información

Este punto está relacionado con el anterior pero enfocado en determinar la necesidad de visualización de datos o de generar información consolidada en forma de reportes. 

Analizar datos con machine learning

¿Tengo o genero datos estructurados para poder abordar procesos de análisis de machine learning?

Controlar dispositivos 

¿Cuento con dispositivos que necesitan ser controlados de forma remota?

Automatizar procesos 

¿Necesito ejecutar procesos de forma planificada y reiterada? ¿Necesito activar o generar acciones puntuales al cumplirse condiciones específicas?

En general se puede también analizar los tiempos, costos y complejidad de realizar integraciones a servicios existentes en contraste con desarrollar las funcionalidades requeridas. 

Es de alguna obviedad verificar que esos servicios efectivamente existen o están disponibles, y en el caso contrario, verificar la viabilidad real de comenzar un desarrollo de alta complejidad. Por ejemplo podemos usar Webpay de Transbank, mas no construir desde cero una herramienta que haga lo mismo solo para usarla en mi e-commerce.

Hacer lo que ya está hecho, es mejor y tiene mejor soporte

En ese contexto, en IDA hay varios casos en los que con el tiempo hemos ido reemplazando el desarrollo propio, por la integración a APIs de servicios de terceros. Básicamente porque ahorramos tiempo y porque con menos esfuerzo obtenemos mucho más de lo que podríamos llegar a desarrollar. 

Es decir, hay plataformas completas que se especializan, por ejemplo, en el envío de emails y que han resuelto problemas complejos. Es el caso de Mailgun que permite automatizar y programar -sin estrés del servidor-, el envío de emails masivos desde un sitio. Algo similar ocurre con Mailchimp y Sendinblue en el caso de los newsletters. 

Otro caso similar es el de Hubspot. Construir un CRM es una tarea titánica y MS Dynamics es una prisión, pero integrarse con Hubspot llega a ser sorprendentemente fácil; tanto que al comienzo hasta asusta ver lo mucho que ganas en información sobre tus prospectos. 

Chequea tus pros y contras

Siempre es sano analizar los pro y contra de cada caso. En cada caso, podemos hacernos las siguientes preguntas:

• ¿Existe un API de terceros o debemos desarrollarla?
• ¿Quiero solo consumir datos o necesito disponer información para que otros se integren a mi servicio?
• Siguiendo el ejemplo del CRM, ¿el equipo de desarrollo tiene conocimiento y experiencia para desarrollar una solución de esta complejidad?
• ¿Podremos construir una herramienta de primer nivel, con todas las prestaciones más innovadoras del mercado? 
• ¿Tengo el presupuesto y tiempo para hacerlo? ¿O, finalmente, es más simple y ventajoso integrarme a uno de los líderes del mercado?

Buenas prácticas

Una vez confirmada la necesidad de integrarse vía API, lo primero es definir los alcances del proyecto. Es fundamental hacerlo y que sea de la manera más detallada posible. No es responsabilidad del desarrollador definir esos alcances. Esta es una tarea que debe hacer el mandante o el Jefe de Proyecto.

Siguiendo con el ejemplo del CRM, no basta con decir “necesitamos conectarnos vía API al CRM”. Esa es una definición tan amplia y simplista que es altamente probable que la solución se vuelva un obstáculo, producto de la falta de definiciones claras al respecto. 

Necesitamos identificar claramente “los datos” que deseamos integrar. Si hay interacciones o micro-interacciones que puedan afectar la lógica de los datos que buscamos ingresar al CRM, por ejemplo, definiendo workflows distintos según la segmentación del prospecto o según el producto que se está cotizando.

Construir tu propia API

En el caso de tener que construir una API para que otras áreas o equipos externos de desarrollo consuman mi servicio, es absolutamente imprescindible considerar dentro de los alcances, la necesidad de documentar tanto la forma de usar la API como de documentar los métodos desarrollados. De esta forma, en caso de errores y futuras correcciones, será más fácil identificar y estimar los esfuerzos de una modificación. A su vez, con las obvias diferencias del caso, este punto también es válido cuando nos integramos a una API ya creada.

En este mismo sentido, también es parte del alcance considerar tiempos para realizar testeos e iteraciones de las funcionalidades desarrolladas. No detectar y corregir errores u omisiones de casos de usos durante la etapa de desarrollo, resultará siempre en correcciones posteriores de mayores costos, tiempos y esfuerzos. 

Recuerda: Un error en producción puede salir por lejos más caro que un error detectado en forma temprana en Desarrollo o QA.

Finalmente, es necesario también considerar el factor “seguridad”. No es por asustar, pero generar un API, en muchos casos, expone información sensible que con sólo un “poco de fuerza bruta” y algo de ingeniería inversa, alguien obtendrá información confidencial sobre nuestros clientes o prospectos. 

En conclusión, puede resultar obvio, pero considerar todos estos factores, marca una diferencia importante en términos de tiempos y costos de un proyecto que sí se hace cargo de cumplir con estos mínimos, versus uno que no. Lo barato muchas veces termina saliendo más caro.  

The post ¿En qué momento nos llenamos de APIs? appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

GraphQL fue desarrollado inicialmente por Facebook en 2012, para ser liberado públicamente el 2015 y finalmente el año 2018 ser traspasado a la “GraphQL Fundation”; organización a cargo de la Fundación de Linux. Desde entonces su adopción ha tenido un incremento sostenido que no nos sorprende.

La API del momento

A diferencia de REST, GraphQL se define como un “Lenguaje de Consulta de Datos” open source. En ese sentido, utiliza Schemas para definir entidades de datos, relaciones y el origen de esos datos, que por ejemplo, puede ser otra API o una Base de Datos.

Las preguntas típicas que podrían surgir y que intentaré responder a continuación, son: 

1. ¿GraphQL significa el fin de REST o de SOAP? 
2. ¿Cuál API es mejor, RESTful, SOAP o GraphQL? 
3. ¿Cuál debo usar?
4. ¿Por qué GraphQL es el futuro?

¿GraphQL significa el fin de REST o de SOAP? 

No, no es el fin de RESTful ni de SOAP. Ambas especificaciones son ampliamente usadas hoy en día. En Chile, por ejemplo, podríamos decir que una de las plataformas más usadas por el comercio es Transbank, y en consecuencia, su API en SOAP también lo es. 

RESTful también goza de gran popularidad en la comunidad de desarrolladores. Casi todas las grandes empresas cuentan con API’s en REST. Hablamos de redes sociales o herramientas como Twitter, Medium, Google y así, un largo etcétera. 

En el caso de REST, WordPress merece una mención especial, porque además de ser uno de los Sistema de Gestión de Contenidos (CMS) más utilizado, desde hace unos años, ha hecho una implementación nativa de RESTful que es extensible y personalizable para distintas necesidades de uso. Por lo que ha impulsado el uso de API RES. Nosotros en IDA, usamos intensivamente esta capacidad para generar nuestros propios endpoints.

¿Cuál API es mejor: RESTful, SOAP o GraphQL? 

En ese contexto tampoco creo que una especificación sea mejor que otra. Creo más bien, que según el contexto de uso puede ser mejor usar uno u otro tipo de API. Dicho de otra forma, si analizamos el requerimiento podemos atender a ciertas ventajas y desventajas respecto de utilizar una u otra implementación.

Por ejemplo, si en el proyecto que desarrollaremos necesitamos un uso acotado, cuando tenemos que procesar un formulario, almacenar un set de datos en la base de datos, gatillar el envío de un email tipo y responder en pantalla con un mensaje estándar; podría desarrollarse rápidamente en REST sin grandes complicaciones. Hablamos de un uso acotado y restringido, en el que solo necesitamos un endpoint y una respuesta estándar. 

Por el contrario, si nuestro proyecto es más ambicioso y queremos construir todo un Theme de WordPress basado en Vue.js o Angular; el que implicaría un uso intensivo de muchos endpoints de una API y donde necesito distintas respuestas para distintas interfaces, entonces me plantearía utilizar GraphQL, dado que las ventajas de su Lenguaje de Queries (de ahí el QL de su nombre), nos puede simplificar y ordenar mucho el desarrollo del backend que proporciona los datos que necesitamos para cada interfaz.

Entonces ¿cuál debo usar?

Aquella que te permita hacer más con menos y en menos tiempo. La que, además, debe ser acorde al requerimiento que tenemos.

Reitero en el ejemplo, si en mi proyecto no tengo grandes requerimientos de integraciones y uso de API, pero tengo que procesar uno o dos formularios, elegiría RESTful. 

Con el siguiente código, podríamos tener lo básico para cumplir lo que necesitamos.

register_rest_route('guardar', 'contacto', array(
 'methods' => 'POST',
 'callback' => 'guardar_contacto',
 'permission_callback' => '__return_true',
 'args'=> array(
  'field_5c63337b5fc7f' => array('required'=>true, 'type'=>'string'),
  'field_5eea92a63c785' => array('required'=>true, 'type'=>'string'),
  'field_5eea92a63c98e' => array('required'=>true, 'type'=>'string')
  )
));

function guardar_contacto(WP_REST_Request $request){
$data = $request->get_params();
$contacto_id = wp_insert_post(
array(
'post_title' => 'Contacto de ' . $data['field_5c63337b5fc7f'],  //campo nombre 
'post_content' => '',
'post_status' => 'draft',
'post_type' => 'contacto', 
)
);

if (!$contacto_id || is_wp_error($contacto_id)) :
wp_die('Error al crear contacto');
endif;

update_field('field_5c63337b5fc7f', $data['field_5c63337b5fc7f'], $contacto_id); //campo nombre 
update_field('field_5eea92a63c98e', $data['field_5eea92a63c98e'], $contacto_id); //campo email 
update_field('field_5eea92a63c785', $data['field_5eea92a63c785'], $contacto_id); //campo mensaje 

$return = send_email_contacto($data['pid']);
$response = get_field('respuestas', $data['pid']);

if ($return) :
$response = $response['exito'];
$response_html = load_template_part('partials/forms/response-exito');
$status = 'success';
else :
$response = $response['error'];
$response_html = load_template_part('partials/forms/response-error');
$status = 'error';
endif;

return array(
'status' => $status, 
'response_html' => $response_html
);
}

En el ejemplo, con pocas líneas de código, hemos creado 1 endpoint que recibe 3 campos de formularios con nombres específicos, donde solo es posible guardar los campos personalizados como un post de borrador en el post type contacto. El sistema mandará un email con formato y texto predefinido y devolverá un status y una respuesta también predefinida para presentar en pantalla.

Pero ¿Cuán seguro es?

El factor seguridad es una consideración importante que me ayuda a tomar una decisión. En el ejemplo anterior, podría verificar el wp nonce y tomar algunas decisiones básicas de seguridad extra, agregando un par de líneas. No obstante, el endpoint programado, al ser muy específico y acotado, no permite que algún bot intruso y mal intencionado se ponga a hurgar donde no queremos que lo haga.

GraphQL -para el caso del requerimiento anterior- pareciera excedernos con creces en capacidades y complejidades. Y es que las lógicas detrás de GraphQL son distintas.

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.

GraphQL se define como un lenguaje de consultas al que podemos responder con data existente. En el caso de WordPress, por ejemplo, nuestra “data existente” son los distintos objetos y APIs internas del mismo WordPress. Como los settings u opciones de WordPress, los Users, los Posts, las Pages, las Taxonomías, etc. 

Así podríamos consultar por un Custom Post Type llamado evento en una cantidad de los primeros 2 eventos creados y donde solo queremos los campos id, eventoId, title y date. 

Cuya respuesta podría verse más o menos así:

Es decir, es una especie de abstracción de la clase WP_Query, pero al mismo endpoint podríamos consultarle por el userId y el name de los Users.

Con los ejemplos anteriores es fácil prever lo simple que sería construir un Theme de WP donde toda la interfaz pública se podría hacer en base a GraphQL y Javascript. En este caso, sólo tendríamos que realizar una o varias consultas según las necesidades de cada vista, sus componentes y módulos.

¿Y el formulario del ejemplo se podría hacer? 

Claro que sí y sería igualmente simple. Del mismo modo que en las API Rest no empleamos llamadas GET para crear o actualizar entidades (usamos POST, PUT o UPDATE); en GraphQL esas operaciones las hacemos a través de mutations.

Según la documentación de GraphQL debemos entender por mutation a una operación que provoca cualquier tipo de cambio en el estado del servidor. 

Un ejemplo muy básico para hacerse cargo solo de guardar los campos del formulario podría ser así:

mutation {
  createContactForm(input: {
 'field_5c63337b5fc7f': "Max Villegas", 
 'field_5eea92a63c785': "info@ida.cl", 
 'field_5eea92a63c98e': "Hola! Este sería el mensaje"
 }) 
 {
    id
  }
}

Más info en https://docs.wpgraphql.com/extending/mutations/

Si bien es cierto que se ve muy simple, al menos en el caso de WP, para hacer esta implementación sería necesario disponibilizar públicamente una serie de Schemas que realmente no queremos o no necesitamos exponer, pues aumentan las posibilidades de que los bots hurguen en nuestra API buscando información potencialmente sensible.

Hoy una forma sencilla de implementar GraphQL es mediante plugins como WPGraphQL. En caso contrario, tendrías que desarrollar tu propia implementación desde cero, con lo que la complejidad inicial obviamente aumenta.

¿Entonces por qué GraphQL es el futuro?

Básicamente porque en desarrollos complejos, que requieren de muchos endpoints para obtener los datos necesarios para construir las distintas interfaces, y donde cada pequeña variación puede implicar crear un nuevo endpoint; GraphQL nos permite simplificar y ordenar, dejando que el cliente decida qué necesita y qué no, a la hora de hacer la consultas de información. 

Según graphql.org, las ventajas principales se resumen en 3 premisas:

1. Pide lo que necesitas y consíguelo exactamente así.
2. Consigue muchos recursos en una petición única 
3. Describe qué es posible con definiciones de tipo

Pide lo que necesitas y consíguelo exactamente.

Cuando envías una query a la API recibes exactamente lo que necesitas, nada más ni nada menos. Las consultas de GraphQL siempre devuelven resultados predecibles. Las aplicaciones que usan GraphQL son estables y rápidas porque ellas, en cuanto cliente, controlan la data que necesitan (o no) del servidor.

Consigue muchos recursos en una petición única 

Las consultas de GraphQL acceden no sólo a las propiedades de un recurso, sino que pueden seguir referencias entre recursos distintos (posts y users). Mientras una API en  REST requiere cargar información de múltiples URL, GraphQL consigue toda la información en un único Request. Aplicaciones que usan GraphQL pueden ser rápidas incluso con  conexiones lentas 

Describe qué es posible con definiciones de tipo

GraphQL está organizada en términos de tipos y campos no de endpoints. Puedes acceder a todas las capacidades de tu data en un único endpoints. Al usar tipos las aplicaciones solo pueden hacer consultas de los datos que son posibles, obteniendo errores claros y útiles en caso de consulta por datos no disponibles. A la vez que las aplicaciones no necesitan “parsear” manualmente un set de datos para obtener solo lo que necesitan.

Un desarrollo menos complejo

En conclusión, con GraphQL podemos simplificar el trabajo de desarrollo y dejar a la capa front muchas de las decisiones acerca de qué datos solicitar al backend para desplegar en las interfaces que construimos.

Sin embargo, esta no es nuestra única opción y a veces, la mejor opción para nuestro requerimiento, será utilizar una api RESTful o SOAP. Utilizar la mejor alternativa dependerá de quée tu proyecto necesite.

The post GraphQL, el futuro de las API appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

Esto no se trata de una tarea sencilla. Cada etapa y herramienta mencionada es parte de un proceso que está lleno de grandes instancias, en donde podemos esclarecer interrogantes y plantear otras, pero sin duda, nos permitirán establecer los lineamientos de nuestros proyectos. 

La historia aún no termina

La aprobación de la propuesta de interfaz (Diseño UI), no es el fin de la etapa de diseño. Aún quedan acciones, hitos y ritos que se deben realizar previos a pasar a la etapa de desarrollo.

En nuestro workshop, definimos y ejemplificamos la importancia de estas acciones. La mayoría de ellas, contemplan trabajo multidisciplinario. 

Para desarrollar, no puede faltar…

Iteraciones en detalle de pantallas críticas

Muchas veces el cliente tendrá un interés especial en iterar sobre ciertas pantallas e interacciones específicas que considera críticas para su negocio. 

Se deben producir la totalidad de plantillas UI comprometidas

La definición de estilos en la Home (página de inicio), no es suficiente para desarrollar un sitio completo. En general es necesario abordar un mínimo de casos, como formularios, resultados de búsqueda, plantillas de email, newsletters, página no encontrada, etc.

Kit UI o Página tipo

Cuando no podemos diseñar todas las plantillas necesarias, una buena alternativa es el Kit UI o, en su defecto, una página tipo. Debemos tener presente que no solo estamos diseñando una interfaz, sino que se trata de un Sistema de Diseño. 

Diseñar las interacciones y microinteracciones

En plataformas como Marvel o inVision, hoy es posible simular estos comportamientos. Los estados hover, visited, focus, active; son alguno de los más básicos y algunas de las que normalmente olvidamos intencionalmente según el criterio y voluntad del Diseñador Front.

No olvides la interacción

Cuando existen flujos transaccionales o sobre el acceso a una información específica, se requieren procedimientos de búsqueda y navegación de mayor esfuerzo, las interacciones se vuelven fundamentales. 

Presentaciones ejecutivas

Cuando diseñas para organizaciones complejas, en el sentido que existen mandos medios, gerentes, directorio y una amplia gama de stakeholders, es estratégico ayudar a tu contraparte directa a socializar el trabajo realizado.

Testear y mejorar

Podemos realizar test de usabilidad de las principales interacciones, de los mecanismos de navegación, de los procedimientos de búsqueda de información y de flujos transaccionales. También podemos hacer test multivariantes y test A/B para medir la efectividad de uno o varios “call to action”. Según corresponda, habrá que definir un guión, contactar usuarios, crear prototipos, aplicar test, sistematizar la información y concluir para aplicar mejoras. 

Una posta donde la entrega del testimonio es la clave

Claramente para llegar al momento del traspaso al equipo de desarrollo, distintos roles y especialistas han participado del proceso. Podríamos decir que en este punto, existe un desprendimiento respecto del proyecto, en el que parte del equipo, debe preparar y consolidar todo el material de trabajo previo, a través de la documentación.  

Hoy, con la infinidad de herramientas y aplicaciones que existen, es relativamente fácil mantener un historial ordenado de los entregables en sus versiones finales. Hablamos de herramientas que van desde Dropbox y Google Drive, pasando por Marvel o Figma hasta plataformas de gestión como Basecamp o Active Collab.

En muchos casos, este traspaso es un acompañamiento constante durante el tiempo que dura el desarrollo. La idea es lograr que los programadores, en el proceso de apropiación del proyecto, puedan ir aclarando cualquier duda que aparezca. De esta forma, podemos alinear la programación con los objetivos requeridos por el proyecto.

Es posible que durante la etapa de desarrollo se identifiquen vacíos de información y se cuestione algunas decisiones tomadas en etapas previas. Por ello, es fundamental contar con un material consolidado que permita validar, refutar o mejorar algún aspecto del proyecto que no haya sido visto con profundidad anteriormente.

Estamos en condiciones de partir

Cuando el equipo de desarrollo está informado de los alcances del proyecto, con sus detalles y objetivos, podrá comenzar su trabajo. Primero, planificando y modelando estructuras, clases, datos, librerías, etc; para luego programar y producir los distintos componentes de la plataforma o sitio. 

Contrastar esta planificación y modelado con el material de las etapas anteriores permitirá cumplir de mejor manera los plazos, evitando cometer errores e iteraciones innecesarias.

Trabajo evolutivo

Será evaluable al final de la etapa de desarrollo, por ejemplo, que el Diseño Front haya interpretado fidedignamente la maqueta de diseño. Esto quiere decir, que debemos respetar colores, tipografías y tamaños. También se deberá evaluar la semántica, optimización y accesibilidad del HTML, tanto como testear la funcionalidad e interacciones.  

Es un hecho conocido que las tecnologías de la información evolucionan a una velocidad vertiginosa. Por eso, también creemos que es fundamental que el desarrollador constantemente investigue y aplique nuevas herramientas, tecnologías y métodos que puedan facilitar y optimizar su trabajo, como también el de sus compañeros.

Una de nuestras premisas es que el desarrollo esté al servicio de la experiencia. De ahí que para nosotros es clave el rol del desarrollador como un facilitador que entienda que la tecnología debe ser una herramienta de ayuda y no una limitante.

The post Marcando pautas para una correcta etapa de desarrollo appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

Para el cliente, este conocimiento, le permite visualizar los estados de avance; prever que obtendrá resultados óptimos; cuantificar lo hecho en cada etapa y corregir el rumbo si se han cometido errores.

Todo el material de trabajo que vamos generado, ayudará al desarrollador a orientar su trabajo y a tomar decisiones óptimas. Siempre en función de los objetivos y acuerdos tomados con el cliente en las etapas previas.

Por ejemplo, el desarrollador no organizará las secciones y páginas del sitio a su antojo o según las posibilidades acotadas por un gestor de contenidos (CMS). Tendrá que elegir un CMS que brinde las condiciones y funcionalidades óptimas para organizar dichas secciones y páginas según el mapa de contenidos, o modificar uno mediante complementos si ninguno lo puede hacer por defecto. 

Es un seguro y una garantía para todos

Pero la documentación no solo funciona como guía de ruta, sino que también podemos entenderla como un seguro frente a los imprevistos; nos otorga control cuando surgen adversidades en el contexto del proyecto. 

Es sabido que un proyecto de largo alcance, pueden pasar muchas cosas. En particular nos ha tocado enfrentarnos a cambios de legislación que afectan a la institución o empresa con la que hemos estado trabajando o nos han cambiado a la contraparte con la que trabajamos directamente. En todos estos casos, poder presentar un trabajo apoyado en material concreto nos ha permitido adaptarnos al cambio y seguir adelante con el proyecto.

Etapas y tareas

Cada etapa tiene una serie de tareas y entregables concretos; no obstante, cada proyecto puede tener configuraciones levemente distintas. En general, recomendamos como base las siguientes etapas y tareas.

Estrategia e inmersión 

Para el éxito de cualquier proyecto, es necesario en una primera etapa, diagnosticar el estado actual de la marca, servicio o producto y su industria. Para esto, recomendamos los siguientes ejercicios de Research.

• Definición de objetivos: Matriz de objetivos que verbaliza y consolida los objetivos que el proyecto debe lograr.
• Auditoría y Benchmark: Presentaciones, extendida y ejecutiva, del análisis de la presencia de la marca en distintos canales y el estado actual de la industria y marcas referentes. 
• Needfinding: Informe de la investigación e insights de usuarios y clientes para construir la propuesta de valor.
• Estudio de tendencia: Informe de investigación de la industria, sus prácticas y tendencias.

Investigación de usuarios

Los estudios de usuarios nos permite tener en conocimiento cuáles son las necesidades y expectativas de las personas que utilizan un servicio o producto. Están orientados a saber sus comportamientos digitales. Algunos métodos que podemos implementar son:

• Estudios de usuarios: Presentación del estudio que identifica a los usuarios que interactúan con el sitio para orientar las decisiones estratégicas en cuanto a la elaboración de Arquetipos. 
• Encuestas online: Herramienta que permite descubrir las características de grupos amplios de personas, a través de un cuestionario digital.  
• Entrevistas: Instrumento que permite conocer en profundidad a usuarios representativos, sus necesidades, expectativas y relación con la marca. Además, sus rutinas de uso y tránsito.  
• Arquetipos: Fichas de personas imaginarias en un contexto específico y con necesidades puntuales que representan a usuarias y/o usuarios del producto o servicio.  

UX Writing 

Las palabras pueden ayudar a las personas a entender de mejor manera una interfaz, a sentirse guiarlos en un proceso o a bajar su incertidumbre frente a algo nuevo. Para su correcta implementación debemos tener un alto conocimiento de nuestros usuarios y tipos de contenidos.

– Auditoría Comunicacional: La personalidad e identidad de una marca se construyen a través de todas las publicaciones que hace una empresa. Algunas de las herramientas generadas en esta etapa son: Estudio de estrategia de contenidos, levantamientos, inventario y revisión de contenidos, producción de contenidos nuevos, benchmark, canvas, guías de estilo, canvas de Microcopy, entre otros.

Arquitectura de Información

Etapa del proceso en donde realizamos mapas de contenidos, diagramas de flujo, partituras de interacción y wireframes.  

• Card sorting: Actividad ágil con usuarios que permite entender mediante la observación los modelos mentales de jerarquización y agrupación de contenidos por parte de estos usuarios. 
• Mapas de contenidos: Diagramas jerárquicos que formalizan las estructuras y relaciones de contenidos óptimas para lograr los objetivos de servicio y cumplir las necesidades del usuario.
• Partituras de Interacción: Diagrama del viaje de un usuario al interactuar con un flujo específico.
• Wireframe: Set de esquemas que nos permite trabajar divisiones de pantalla para satisfacer los distintos despliegues de contenido a través de todo el sitio bajo estructuras establecidas. 

Diseño de interfaces de usuarios

El diseño de interfaz de usuario de cada proyecto está basado en la línea gráfica de la marca, producto o servicio. 

• Definición de estilos Digitales: Sintetizamos la información e interpretamos conceptos y jerarquías para crear plataformas fáciles de usar.
• Propuesta de interfaz: Fortalecimiento de la identidad visual de la institución para que sea reconocible por sus usuarios en los canales digitales.
• UI Kit: Librería de elementos que permite estandarizar los distintos elementos gráficos del proyecto.  

Si bien, aún quedan etapas por abarcar el paso del Diseño al Desarrollo, este debe estar guiado y compuesto por una serie de procesos que dan forma y sentido a los proyectos en los que nos vemos involucrados. Del mismo modo, es sumamente importante que los equipos sigan una lógica de conocimiento compartido para que los traspasos sean eficientes.

No podemos olvidar que el diseño de interfaz y desarrollo, son partes de un proceso más grande; por lo que cada miembro debe sumergirse siempre en la información obtenida en las etapas previas.

The post Del Diseño al Desarrollo: Conocimiento compartido para alinear proyectos appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

Lo cierto es que tanto los pesimistas como los optimistas tienen razón. La reinvención y los cambios de planes han sido el común denominador en estos meses de confinamiento.

En mi caso, uno de esos planes personales era realizar una serie de talleres online; claramente no lo hice. Sin embargo, en IDA, desde abril hemos estado haciendo workshops online casi todos los jueves. Otro de esos planes propios era avanzar en el trabajo remoto y ¡Adivinen! De un día a otro estábamos todos trabajando en nuestras casas.

Un poco de historia

Al comienzo de IDA -hace ya 10 años- todo era remoto y virtual. Maximiliano estaba en Viña del Mar, Fito en Italia y yo en Santiago. Pero luego se sumaron Alberto, Fernando y Jorge, y así, casi sin darnos cuenta, éramos siete, ocho y luego, diez personas con la necesidad de tener una oficina cómoda donde trabajar. 

De forma más o menos natural, la organización con el equipo era in praesentia en la oficina. Si tenías dudas simples te acercabas a tu compañero de puesto y lo resolvías. Por cierto, usábamos Basecamp por herencia y porque era la mejor herramienta del momento. Nos servía tanto para mantener un registro e historial con clientes, como para tener ese registro compartido con el equipo y no perder información durante el desarrollo de una tarea o proyecto.

Obviando el ciclo de contactación y reuniones presenciales con clientes y prospectos, gran parte de nuestro trabajo (desde el punto de vista del cliente), siempre ha sido remoto. Sin embargo, la organización interna se resolvía mayoritariamente en breves reuniones informales o largas y masivas reuniones formales. En cualquier caso, la coordinación de tareas, tiempos y personas (clientes incluídos) es una problemática multifactorial y de gran complejidad.

Cómo llegamos hasta aquí

Pero en el mundo, durante estos diez años, las cosas cambiaron harto. ¡Vaya novedad! Vivimos la consagración de las redes sociales, la aparición y ascenso de plataformas de mensajería de distinta índole. Todo se nos volvió “aquí y ahora” con WhatsApp; todo se nos volvió integrable con Slack; todo se nos fue a la nube y se nos hizo aplicación. 

Nos llenamos de aplicaciones y plataformas. La información muchas veces nos llega por más de una vía (a veces duplicada, a veces disgregada). Y sí, sufrimos de aplicacionitis e infoxicación crónica.

Pero esta modernidad algo caótica y llena de plataformas de trabajo colaborativo en línea tiene sus ventajas. En el contexto pre estallido social de Chile, con Andrea y Rodrigo, veníamos impulsando con cierta cautela, jornadas de trabajo remoto. 

La dirección de Andrea estuvo por más de un año orientada a evaluar de qué manera podríamos ordenar los flujos de trabajo con el equipo y así mejorar la experiencia general de todos. Parte fundamental de esa experiencia era posibilitar cada vez más jornadas remotas. Algo que no es fácil cuando estás atado mentalmente a lo presencial.

Sin embargo, en octubre llegó el estallido social y cinco meses después, la pandemia. Fue el momento en el que el confinamiento hizo del trabajo remoto, la norma. Y nosotros asumimos el desafío.

Cambio de estado

Más allá de las herramientas, aplicaciones y plataformas que comenzamos a usar para organizar el trabajo, el confinamiento nos hizo cambiar de estado mental. Nos puso en una  disposición distinta respecto del uso de tales o cuales herramientas; y de un conjunto de hábitos colectivos de trabajos.

Al desaparecer los límites espaciales entre el hogar y el trabajo, se volvió absolutamente necesario poner límites temporales en el trabajo. Para ello, claramente es necesario ser más eficiente en la organización de tareas y de los tiempos que le dedicamos a cada una. 

El problema es que entre tanta aplicación y plataforma, es fácil perderse y terminar siendo poco eficiente. Terminamos dedicándole más tiempo a entender y gestionar cada herramienta que a las tareas propiamente tal. A esto, también debemos sumarle los malos hábitos y experiencias propias. Lo que a uno le resulta más cómodo, cercano, comprensible y fácil, otros no. Y como si fuera poco revoltijo, el componente “necesidades de la organización de cara a clientes”, suma unos cuantos ingredientes extras.

Adiós Basecamp, Bienvenido Jira

En particular, después de más de 10 años usando Basecamp, y habiendo sumado una larga lista de aplicaciones secundarias en este recorrido, necesitábamos una herramienta que nos acompañase de mejor manera en nuestro estado actual y futuro. Una que nos permita adaptarnos a nuevas prácticas, ritos y hábitos actuales. En definitiva, con la cultura e identidad presente incrustada en el contexto productivo nacional y mundial.

La elección de nosotros fue Jira. Entre tanta plataforma similar, honestamente, aún no sabemos si es la mejor. Sí, probamos algunas otras como Active Collab, Harvest y Trello sin realmente llegar a convencernos. Desde febrero, poco antes de la pandemia, estamos en el proceso de aprender todas sus posibilidades y modelar según nuestras necesidades los flujos de trabajo en los distintos tableros de proyectos. 

Hay riesgos inevitables en la transición. La resistencia al cambio siempre se expresa en todas sus aristas y, por cierto, habrá que tratar de mitigar esos riesgos y temores. Sabemos que no es fácil hacerlo y que no hay recetas mejores que otras. 

Adaptación constante

Hasta el momento, no sabemos si es la mejor herramienta, pero más allá de sus complejidades; es moldeable y flexible en muchos aspectos y esa fue la razón de su elección. En comparación con Basecamp, Jira es obviamente más moderna y, de entrada, tiene la capacidad de integrarse con Slack, Marvel, Dropbox y otras tantas aplicaciones más. Entre ellas, Bitbucket, que es nuestro repositorio GIT desde hace 5 años o más. 

En la dicotomía presencial / remoto, el desafío inmediato ha sido pasar al teletrabajo de un día a otro, con el menor impacto posible. Ante ello, Jira, así como Meet, nos han ayudado a hacer más llevadero ese cambio. Era lo obvio y esperable. Pero el desafío de los próximos años va más allá. Se instala en el eje sincrónico / asincrónico, para eso, espero que Jira nos ayude bastante más.

The post Adaptación constante: En la búsqueda de la herramienta perfecta appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

¿Por qué terminamos hablando de taxonomías en un contexto de Arquitectura y Desarrollo?

Identificamos que era la excusa perfecta para levantar el tema de la comunicación entre equipos de Arquitectura de información y Desarrollo. Aplicable también para equipos de diseño. Como comentamos arriba, en determinadas situaciones, las conversaciones o traspasos de proyectos entre un AI y un Dev pueden evidenciar una falta de consenso.  

Dicho lo anterior, debemos declarar que nuestro principal objetivo al abordar este workshop; más allá de compartir conocimientos, fue abrir la discusión sobre el estado de la comunicación entre Arquitectura y Desarrollo. 

Lo hacemos a nuestro estilo, compartiendo, disponiendo un tiempo y un espacio para reparar en ciertos dolores que nos han acompañado en estos 16 años trabajando juntos. Hemos enfrentado, igual que en la película “El día de la marmota”, una y otra vez el traspaso desde las etapas de arquitectura a las de desarrollo. 

En este workshop respondemos una de las preguntas que en {ida tiene más tintes de convicción. El por qué es necesario que los arquitectos conozcamos en la práctica el desarrollo, y a la vez, los desarrolladores sepan interpretar de forma correcta un mapa de contenidos y aplicarlo como corresponde. Levantantando dudas y proponiendo mejoras.

Hay conocimientos teóricos que serán adquiridos en la literatura correspondiente, pero están las habilidades prácticas que, ciertamente, es difícil traspasar a equipos jóvenes. ¿Cómo transferimos la experiencia de la praxis?

¿Cuál ha sido tu experiencia comunicacional con estas u otras áreas? ¿Tienes dolores similares? Los invitamos a comentar su experiencia y a revisar el workshop de Arquitectura de información, Taxonomías y Desarrollo, en nuestro canal de YouTube. En el cual revisamos algunas definiciones (que están a continuación) y realizamos una demostración en vivo del traspaso de un Mapa de Contenidos al equipo de Desarrollo.

¿Qué es la Arquitectura de Información?

Para responder esta interrogante podemos encontrar una serie de definiciones que nos permitirán entender de mejor forma este concepto. Estas son:

• Diseño de estructuras de contenidos para sistemas de información.
• Procedimientos de organización, etiquetado, búsqueda y elaboración de sistema de navegación para sitios e intranet.
• El arte y la ciencia de dar forma a productos y experiencias de información para apoyar la usabilidad y la capacidad de búsqueda.
• Una disciplina emergente y una comunidad de práctica enfocada en llevar los principios del diseño y de la arquitectura al entorno digital.

¿Qué es una taxonomía? 

Podemos encontrar distintas acepciones, pero en general hablamos de una forma de clasificar elementos, es decir, de la operación mediante la cual agrupamos una serie de componentes  con características comunes dentro de un mismo conjunto o clase definido por dichas características. Entre estos podemos encontrar a:

• Ciencia: ordenación jerarquizada y sistemática de los grupos. Ejemplo: reino animal y reino vegetal, vivíparos, mamíferos,  caninos… 
• Lingüística: Relaciones semánticas y léxicas. Ejemplo: sinonimia, hiperonimia, hiponimia, antonimia y cohiponimia.
• Matemáticas: Teoría de conjuntos. Números naturales, números primos, números pares, impares, etc.
• Bibliotecología: Clasificación del conocimiento en función de las características del contenido.

¿Qué es un tipo de contenido? 

Los sistemas de clasificación constituyen una segmentación y estructuración arbitraria y convencional del conocimiento, con el objeto de crear categorías, que luego puedan ser asignadas a los ítems para organizarlos física y lógicamente en una colección.

En ese sentido un sistema de clasificación se caracteriza por: 

• Organizar documentos de forma convencional.
• Agrupar conforme a determinados criterios.
• Facilitar los procedimientos de búsqueda y selección de un documento. atendiendo a tales criterios convencionales.

Los criterios de clasificación pueden ser establecidos acorde al significado o a la forma:  

• Literatura > ciencia ficción v/s Historia Universal > Historia Latinoamericana.
• Revistas v/s Libros.
• Novela v/s Noticia.

¿Qué es el contenido en el contexto de un CMS? 

El contenido es la información producida mediante un proceso editorial, que tiene la intención de ser publicada para ser consumida por humanos. En ese sentido debemos considerar que: 

• El proceso editorial es un flujo de trabajo humano, que puede comprender diferentes etapas como el modelado, edición, revisión, aprobación y publicación del contenido.
• El contenido siempre es consumido por una audiencia. Ciertamente va a transitar por diversos dispositivos, plataformas, API’s, redes, pero en algún punto va a ser consumida por un humano.
• Nunca son simplemente datos o información, aunque la diferencia puede ser difusa y polémica en ocasiones.

Si quieres saber más sobre herramientas, ejercicios y metodologías de trabajo en experiencia de usuario, no te pierdas nuestros próximos {ida Workshop. Únete a nuestro grupo de Meetup y síguenos en nuestro canal de YouTube para no perderte ninguna novedad. ¡Nos vemos!

Algunas lecturas sugeridas 

• Information Architecture: For the Web and Beyond 
• Una introducción a la teoría literaria 
• Web Content Management: Systems, Features, and Best Practices 

The post Por una comunicación virtuosa entre arquitectos y desarrolladores appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

Dicho lo anterior, es necesario agregar que el 2016, cuando Fernanda Zúñiga lideraba el área de diseño, publicamos una serie de videos animados, por lo que hoy, esta idea tampoco se ve muy novedosa: es algo en lo que ya habíamos incursionado.

¿Entonces, por qué insistir? Porque creo que esa vieja premisa de “cambiar para crecer” funciona. Con el blog nos hemos posicionado y diferenciado de la competencia, pero ya no estamos tan solos como cuando partimos el 2013. Además, tras seis años generando contenido de valor en torno a temáticas afines a nuestro rubro, sentíamos que era el momento de salir de nuestra zona de confort y hacer algo diferente.

Los Martes son de UX

El desafío no ha sido fácil. Ahora se trata de estar frente a la cámara, de exponernos, de generar opinión, de explicar y enseñar sin aburrir sobre temáticas que no son de interés masivo. En cada nuevo video se mezclan las expectativas y las frustraciones, la ansiedad y los pequeños éxitos alcanzados. 

La motivación, no obstante, es simple e inequívoca. Buscamos pasar de la lógica individual del texto escrito al diálogo de una conversación entre amigos. Queremos exponer diferentes puntos de vista, con la idea clara y subyacente de que ese diálogo se expanda, que sume a otros actores y en consecuencia, se enriquezca con otras experiencias y opiniones.  

Ya no se trata solo de contar lo que hacemos. Ahora hay caras que tienen tras de sí una vasta experiencia profesional en el rubro y un pensamiento crítico desarrollado al fuego lento de la práctica y la teoría. Esa es la materia prima del contenido de valor que queremos generar.

Nuevos desafíos

Salir del área de confort no es fácil. Así como el blog requiere una serie de aspectos técnicos que van desde la semántica del código, pasando por las estrategias de SEO, hasta contar con un diseño de interfaz simple y usable. El formato de video implica manejar una serie técnicas tan variadas como la ecualización del audio, la iluminación, los ajustes de las cámaras, la edición y un largo etcétera. Y no es baladí. 

En ese contexto hoy no es separable el fondo de la forma. El contenido puede ser muy interesante, documentado y académico si se quiere, pero si tiene problemas técnicos, será rápidamente “saltado” al siguiente video que ofrezca el mismo contenido, pero que cuente con mejor técnica, mayor dinamismo y más carisma. Y la oferta es amplia.

De la misma manera que con el blog era necesario entender que no podíamos caer en la pedantería académica ni en la idea ufana de “documentar” Internet, con Youtube es preciso entender que se trata de un “show”, de un espectáculo o un montaje. 

Estoy convencido de que podemos y debemos entregar un contenido valioso para nuestros usuarios. Ya sean colegas, clientes, estudiantes o académicos; pero no debemos olvidar que debemos hacerlo de una manera entretenida, digerible y acorde a los cánones de la plataforma.

Trabajamos cada día para aportar, desde nuestra experiencia, a la conversación sobre la disciplina que nos ha motivado por años. Con Los Martes son de UX asumimos un desafío técnico, siempre manteniendo la idea de generar comunidad y compartir la forma en que entendemos nuestro rol en la industria.

The post La importancia de tener un canal de YouTube appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.

La utopía sobre una Internet libre, parece haberse volcado, a un Internet más insegura. Y no por las empresas, ni las personas. Sino por los datos. Aunque sin lugar a dudas, hay cosas que han convergido. Y algo de eso, sí podemos agradecerle al cyberpunk y la ética hacker.

Héroes de la revolución digital

El periodista Steven Levy, escribió el libro Hackers: heroes of the computer revolution en  el año 1984,. En este libro, Levy define los valores o lineamientos que cualquier hacker debería seguir como programador y persona.

En los 80, el mundo se movía entre la guerra fría, y en Sudamérica, diferentes países atravesaban golpes de Estado. Internet era un territorio nuevo, inexplorado, y difìcil de comprender y compartir. Esta fue la primera vez que se habló de una ética hacker en el mundo. Asentando las bases para lo que sería la programación y los movimientos informáticos del futuro.

Steven Levy recopiló en su libro, la historia tras grandes personalidades de la programación, que usaron su conocimiento, en beneficio de diferentes sociedades. Algo, que para nuestra época, estaría representado por Julian Assange o Edward Joseph Snowden y sus grandes revelaciones.

En base a los hechos y la historia tras cada hacker que ejerció entre los años 50, 60 y 70, Levy enumeró los seis valores que todo Hacker Ético, cumple y debe cumplir:

• El acceso a las computadoras debe ser ilimitado y total.
• Toda la información debe ser gratuita.
• Desconfianza de la autoridad: promover la descentralización.
• Los piratas informáticos deben ser juzgados por su piratería, no por criterios falsos. como los grados, la edad, la raza o la posición.
• Puedes crear arte y belleza en una computadora.
• Las computadoras pueden cambiar tu vida para mejor.

Esto, no fue sólo una declaración de principios. También dividió a quienes se inclinaban por la lógica comercial, versus la filosofía de usar la tecnología para el bien. Al igual que lo hace el código abierto y software libre.

Sin embargo, en la medida en que creció el acceso a la Internet y sus tecnologías, esto cambió. ¿Qué ética definimos dentro de una web 2.0? Tras la hipermediación, y la creación del smartphone, ya no estamos tan de acuerdo con la conexión ilimitada y total. Tampoco sabemos si desconfiar sólo de la autoridad. Todo ha cambiado.

La utopía de la seguridad y la libertad

En el ecosistema actual de Internet, y también, en el día a día de las personas, la seguridad es lo primero. Y tras los casos de venta masiva de información, como el de Cambrige Analytica, sólo nos hicieron desconfiar aún más de las tecnologías.

Hoy, la concepción sobre la Ética Hacker, ha migrado hacia el mercado. Cada día hay más empresas que ofrecen servicios de seguridad informática bajo principios similares a los originales.

Si bien, esto no es un síntoma únicamente de la web, sino de la sociedad. Hoy en día nos vemos envueltos dentro la industria de la seguridad. Ya sea en el hogar, en Internet, en nuestro transporte. Queremos sentirnos seguros. Antes queríamos acceso a todo, pero ahora, tenemos miedo de que accedan a nosotros.

La ética hacker en la actualidad

En el contexto de una Internet incipiente, que existieran estos lineamientos éticos era necesario para cualquier persona que trabajara en el área digital. Muy pocas personas en el mundo, tenían un conocimiento vasto del tema; por lo cual, utilizar el conocimiento como utilidad personal era una posibilidad frente a sistemas desprotegidos o muy privados.

Ahora, el contexto es diferente. Todas las personas tienen sus datos en Internet, y son datos sensibles que debemos proteger. Sabemos que no todo puede ser público. Y ante eso, el cambio de consciencia ha sido generalizado.

Los gobiernos cada día abren más sus datos bajo la lógica del Open Gov, y al mismo tiempo, las personas se alejan de las redes sociales por miedo a ser vulnerados. Nuestra necesidad actual se centra en saber qué tan observados y autónomos somos, al mismo tiempo que nuestros derechos se respetan y podemos expresarnos libremente.

Esa es la discusión actual. Sabemos que en continentes como Europa, las leyes van hacia la protección de los ciudadanos. Mientras que en China, el gobierno tiene el control y en EE.UU. el capital es prioridad. Sin embargo, tampoco sabemos cuál será la opción con mejores resultados en el futuro.

The post Ética hacker en la actualidad appeared first on Blog IDA Chile | Estrategia para el éxito de tu negocio.