Web o Desktop?

Mientras leía el post Web o desktop? en Software Guisho, pensaba en lo lindo que es poder iniciar un proyecto pudiendo decidir uno mismo que tecnologías usar, enfoques y si cabe lo que dice el título: lo hacemos web o desktop?

Precisamente hay una corriente a llevar todo lo posible a la web, los programas de toda la vida, los que siempre corrieron sin problemas en nuestra PC a la web, lo distribuido, lo siempre online. Ahora, creo que si bien es cierto que hacer un aplicación web tiene sus ventajas (muchas por cierto) y sus desventajas, hay que diferenciar varias cosas, para empezar: lo hacemos web o lo hacemos con tecnologías web?, creo que aquí podemos hilar fino y diferenciar un par de cosas. Considero que una aplicación es web cuando hace uso de todo el stack web, es decir, reside en un servidor, se comunica con el cliente mediante peticiones HTTP (generalmente, no siempre), y finalmente interactuamos con ella a traves de un navegador, es más, me traigo la definición de Wikipedia: 

"En la ingeniería de software se denomina aplicación web a aquellas aplicaciones que los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador."

Muy bien, ahora si yo realizo una aplicación que trabaja offline exclusivamente, que resida en local por ejemplo sin siquiera necesitar el servidor o el acceso a la red, un simple archivo HTML que el usuario abre con el navegador, es una aplicación web? o solo utiliza tecnologías web tales como HTML, CSS y JavaScript? El ejemplo puede pecar de sencillo, nadie hace (me imagino yo) una aplicación medianamente útil en un simple archivo, pero... porqué debería ser simple? Los navegadores van camino de convertirse en plataformas de desarrollo completas, la "nueva maquina virtual" leí por ahí, por la capacidad de darnos un entorno más o menos controlado y poder abstraernos de la plataforma subyacente, léase SO's, arquitecturas y demás variables.
Esto siempre fue así, pero con todos las novedades que trajo HTML5 (y no digo traerá porque varias ya las tenemos disponibles, sí hoy, en mi navegador y seguramente también en el tuyo) sumados a nuevos enfoques (SPA, MVC client-side, bus de eventos, Thin Server Architecture...  la época de la librería JS solo para eye-candy quedo atrás) tenemos a nuestra disposición toda una serie de cosas que antes estaban reservadas a las aplicaciones desktop como bases de datos locales o el multiproceso en background, o que éstas ni siquiera tenían como el manejo de historial para diferenciar tareas y recordar sus estados, varias de estas características tienen la posibilidad de trabajar completamente offline, junto a otras menos conocidas forman un entorno muy interesante.
Pensándolo bien no suena tan descabellado una aplicación que usara todo esto de manera exclusivamente local sin necesidad de un servidor remoto, solo parte del stack web, perdería la mitad de la gracia pero que es posible seguro.

Y el Cloud?

Es verdad que hay como una "manía" de migrar toda aplicación que se pueda a la web, potenciado por todo el ruido del Cloud que reflota las bondades de toda la vida y algunas nuevas: no solo distribuido, accesible, multidispositivo, sino que los desarrolladores también optimizamos almacenamiento, recursos hardware ahorrando energía, es ¿mas seguro? que tener nuestros datos en local (supuestamente usamos sistemas redundantes y tolerantes a fallos), costos, mantenimiento, todo color de rosas. Aunque muchos de los tópicos solamente son aplicables a los que manejan datacenters y no todos son relevantes para nosotros los desarrolladores de apps, hay que reconocer que son cosas tentadoras de que formen parte de nuestra arquitectura, y de nuevo, suman y nos inclina la balanza. Estas ventajas no son de uso exclusivo de una aplicación full-web, pero hablan el mismo idioma.


Tenemos también los efectos colaterales: la progresiva migración de las aplicaciones a la web y su consiguiente maduración nos familiarizó otro concepto: usabilidad, si bien esta área hace tiempo que existe, en el diseño para la web es donde encuentra su punto álgido, su mayor representación, un tópico que es cada vez más tenido en cuenta y suma puntos para un mejor trabajo. Ahora, alguien recuerda la usabilidad de los programas de escritorio?, sacando el software de cabecera (las aplicaciones con años en el mercado o mucha industria detrás que financie mejoras continuas) el resto deja mucho que desear, nadie se extraña si en un local comercial u oficina hay alguna aplicación de letras verdes sobre fondo negro (no necesariamente de consola, cuidado), si ese programa es portado a la web alguien pensaría por un instante en hacerlo de la misma forma? creo que no. Incluso las empresas de desarrollo que trabajan a menudo con tecnologías web poco a poco incorporan este concepto a sus productos.
Sin duda la mentalidad es otra, incluso esas aplicaciones típicas SAAS, me refiero a los refritos de CRM's de toda clase que surgen como hongos, incluso hasta los más inmaduros tienen una interfaz cuando menos agradable, lo cual ya es mucho decir. No importa si como el alcance es global los players se multiplican y por eso hay que poner cuidado en lo visual, es un paso adelante y los usuarios agradecidos. Me a pasado de tener un par de mejoras estéticas simples, pero cuando vuelves a la interfaz anterior ya las hechas de menos, es hasta gracioso, como esa receta para  un "logo web 2.0", que si bien es una tontera ya nos indica algo, como que hay un diseño 2.0 y otro que no lo es, algo que esperamos que este ahí aunque no sepamos de que se trata.


Entonces?
El tema es que hay aplicaciones que naturalmente tiene sentido que sean web, básicamente todas las que involucren acceder a un recurso compartido que este medianamente centralizado, las redes sociales por ejemplo, los datos tiene que estar en algún lado al que podamos acceder todos, y dejando de lado algunas frikeadas lo más lógico es un prestador de servicio y una serie de  consumidores que accedan a los mismos, igual para los portales de noticias, blogs, buscadores o similares.

Pero por otro lado, y donde es difícil contradecir a los evangelizadores del "todo web", ¿hay aplicaciones que no tenga sentido llevar a la web?, aquí ya no es tán facil la respuesta, y en caso afirmativo, porque no?

Una de la cosas que más se criticaba era la vuelta al "cliente tonto", donde el PC volvía en el tiempo para convertirse en un equipo de escasos recursos que solo se utiliza para acceder a la red, delegando en un servicio remoto la persistencia/procesamiento de los datos, los documentos, archivos, configuraciones y demás, ok, pero veamos un poco más en detalle: esto solo lo podriamos aplicar en el caso de las aplicaciones thin-client, no en términos hardware, sino en términos web, típico portal de la intranet que lista recursos y nos habilita el CRUD, la página web de toda la vida, pero y las verdaderas aplicaciones web?, es decir, las aplicaciones pesadas en el cliente (cuidado, no sean asnos y le llamen fat-clients, es más elegante: rich-client apps), esas que sí hacen un uso extensivo de los recursos hardware que posea el equipo.

Miremos a corto/mediano plazo: en lo inmediato ya tenemos aceleración por hardware de gráficos en el navegador, algunos más avanzados que otros pero es un feature que llegó para quedarse, iniciativas como el WebGL necesitan sí o sí este tipo de recursos para una experiencia medianamente fluida, pero en el futuro inmediato tenemos WebCL, la posibilidad de acelerar el poder de calculo de JavaScript mediante GPU, los demos sobra decir son IMPRESIONANTES, así que tenemos aceleración por harware en gráficos y nitro puro en el lenguaje de programación (no utilizo JavaScript solamente porque tambien esta DART, por ahora  irrelevante pero con Google detrás nunca se sabe). Esto en el campo de potenciar las tecnologías más extendidas, pero no hay que olvidarse de NaCl, otra  propuesta de Google para ejecutar código nativo compilado (C/C++) en una sandbox dentro del navegador, aquí tendríamos uso extensivo de recursos del PC, también los procesos independientes por pestaña o plugin en Chrome van en la linea de aprovechar al máximo el hardware ganando de paso estabilidad en la ejecución, otra tendencia en ascenso.

Si miramos a más largo plazo tenemos WebRTC (no te gustan los acrónimos? dos platos!), básicamente un conjunto de tecnologías disponible para los fabricantes de navegadores que habilita tareas en tiempo real, la típica videoconferencia pero se supone que irán apareciendo cosa más interesantes. Sumo otra tendencia  no tan nueva que dejo para un post completo: la aparición de las arquitecturas SOFEA que calzan en este enfoque, trasladando gran parte del trabajo (no todo) al cliente.

Con todo esto tenemos que la vieja idea de que el tema pasa por el uso o no de la potencia de cálculo local ya pierde fuelle, pero repito: potencia de cálculo local, no digo recursos locales, y aquí es donde creo finalmente llegamos a la línea divisoria: el acceso a los recursos hardware, al sistema de archivos (cada vez menos relevante pero hoy día está ahí) y más importante, el acceso a los periféricos, al USB, al asqueroso puerto serial de toda la vida (nadie se asombre: scanners de algunos años o lectores de tarjetas). Sin ir más lejos te invito a que la próxima vez que vayas al super observes el tipo de conectores que disponen las balanzas.

Algunos apuntes

Me quiero detener en un algunos puntos, primero el hámbito: hay que diferenciar el uso casual del uso laboral, en el primer caso creo que la disyuntiva está ganada, yo mismo si enciendo el PC y no tengo acceso a Internet, no importa que fuese a hacer, ya me entra una apatía indisimulable, el navegador debe ser por lejos la aplicación más utilizada por cualquiera aquí y sobre cualquier plataforma.
Pero en el entorno laboral la cosa cambia, esas aburridas aplicaciones de facturación, gestión de documentos o planillas de calculo hay veces en que es hasta deseable que no tengan conección a Internet, por seguridad o porque sencillamente no la necesitan y así funcionan tan campantes desde hace años, ahora, no les aseguro les quede mucho por delante trabajando desconectados.

Segundo, otra cosa en que quiero profundizar es en lo del acceso al sistema de archivos local, si bien esto se espera se dé cada vez menos, como mencionaba en parte a la tendencia a lo cloud, donde nuestros archivos estarán cada ves en menor medida en nuetro equipo, no oculta el hecho de que los navegadores no están diseñados para manejar recursos locales, simplemente no están hechos para eso, en todo caso el manejo de archivos se limita a la tarea de enviarlos a un servidor externo mediante el botón de upload, no tienen capacidad de acceso decente, en todo caso te dan un explorador básico, permiten abrir un manojo de tipos de archivos, pero más allá de eso tenemos que recurrir a extenciones, addons o plugins (cuidado, esto no es exclusivo de los navegadores, el mismo explorador de archivos de cualquier SO no maneja todos los tipos de ficheros obviamente), pero la idea queda clara: el navegador es para acceder a recursos externos, no locales.

Esto puede cambiar en un futuro no muy lejano, particularmente con la popularización de los smartphones los browsers se ven tentados a incluir cada vez más capacidades de acceso al hardware del equipo solventando así más situaciones, volviéndose más capaces, aún así hay un fenómeno curioso con estos dispositivos: en un principio las aplicaciones funcionaban básicamente en local, no accedían a Internet. Luego con la masificación del WIFI, el 3G, ya con  el acceso a la red como algo trivial, todo parecía migrar otra vez al navegador, pero en cuanto las capacidades hardware comenzaron a aumentar la tendencia se revirtió, la mayor parte del tráfico de Internet hoy se da desde aplicaciones, no desde el navegador, desde software instalado en local, otra vez pantallas de inicio plagadas de íconos multicolores en lugar de marcadores y el arribo de las tiendas de aplicaciones, extraño no?
- no pasemos por alto sin embargo que esto de las appstores no solo crean un nuevo mercado de oportunidades sino que también es un ambiente más controlado por los fabricantes que la web, cuidado con esto -

Creo que el fenómeno se explica de la misma manera, amplificado porque lo móvil tiene el foco de la industria y los cambios de procesan y adoptan de manera mucho más rápida, en mi forma de ver es lo mismo, solo que en los smartphones no hay USB, no hay archivos locales, lo que hay es cámara de fotos, más acelerómetro, más velocímentro, más GPS, más Bluethot, más RDF, y por fin sí: más USB, más  archivos locales, y ahí el fenómeno se repite, el navegador se queda corto y necesita entrar en acción algo una capa más abajo, algo que corra sobre el bare metal, y ahí no hay chance, las aplicaciones nativas llevan delantera.

Por último quiero mencionar el uso del concepto de API's como medio estándar de interactuar los recursos, sean hardware como mencionaba o remotos, cualquier aplicación o sevicio hoy día tiene que tener un  medio estandarizado de comunicarse o exponer los recursos contenidos, incluso era la carencia que más se le reclamaba a Google+  en su salida, y salvando las distancias entre una red social masiva y un software para la oficina, todo esto trae aparejado un concepto: hoy el software totalmente standalone no tiene cabida, a menos que sea algo muy puntual o simple, en su lugar se potencia el ecosistema de aplicaciones, dejando de paso más margen para hacer negocio, de nuevo un concepto que  ya existía pero que en lo web encuentra su mayor expresión: que una extensión para esto, que un módulo extra, que freemium, que límite de consultas gratuitas y la lista sigue.
Las aplicaciones de escritorio claro tienen toda una serie de cosas para comunicarse, algunos implementamos un RMI, otros usaban un socket y escuchaban, alguno tiene embebido un nevagador, de todo, ahora en un ambiente web esperamos desde el vamos una URL y una serie de operaciones REST, SOAP o lo que sea, pero esperamos que estén ahí, sin complicaciones, hoy día el consumo de API's -públicas o no- es moneda corriente, encontrando su máxima expresión en los mashups, otros que cada vez tienen más huecos en el mercado.

Retomando si Web o Desktop no quiero dejar de mencionar un tercero en discordia, el llamado desarrollo híbrido, un enfoque para mi acertadísimo ya que nos da lo mejor de dos mundos. Este término no es tan nuevo, si bien puede aplicarse a cualquier cosa que mezcle un par de tecnologías con foco diferente, aquí lo referenciamos en el caso del desarrollo para desktop que hace uso de tecnologías web. Esto es interesante ya que tiene una serie de ventajas, la primera es utilizar todo el knowhow de desarrollo web volcado al escritorio, no solo es novedoso, hay veces que no tienes tiempo/ganas/recursos de aprender una tecnología según cada SO. La mayor parte de las veces consiste en utilizar un motor de renderizado de HTML + CSS, un intérprete de JavaScript (alguien dijo un navegador sin botones?) envuelto en alguna suerte de wrapper que permita instalarlo como una aplicación ejecutable más y nos de acceso a las funciones de bajo nivel del SO que generalmente no teníamos en el caso del browser puro (tray icon o integración al menú contextual por ejemplo).

Es cierto que te quedas en un "a medias", que no es ni full web ni full desktop, pero prefiero verle el lado positivo, ya que repito te da lo mejor de dos mundos y para nosotros los desarrolladores web tiene un plus no menor: programas para un solo navegador, nada de diferencias según lo que tenga el cliente.

En mi caso puntual (luego de haber ensayado otros enfoques como JWS) estoy probando la plataforma Titanium que peca de estar un poco verde, sobre todo la documentación, otra que promete es QT con el módulo QtWebKit, pero aquí trabajamos con C++ sumándole la idiosincrasia de QT, solo para valientes, quizás más adelante :)

Para ir rematando creo que la discusión es más profunda pero repito me quedo con la impresión de que cada ves tiene menos sentido tener aplicaciones solo desktop, al menos en la empresa donde generalmente son complejas y preferiblemente necesitan intercomunicarse con el mundo exterior (que no con Internet, cuidado aquí), creo que de a poco van a ir evolucionando pero en un enfoque más como los smartphones, aplicaciones locales con las ventaja de estar conectados por default, de tener los recursos más accesibles desde fuera o exponer los propios. Aunque una migración a tecnologías full web no siempre tiene sentido creo integrarán en menor o mayor medida cada vez más servicios externos, y si vamos a encarar un desarrollo, mejor ir previniendo y utilizar la tecnología que está desde el vamos creada para eso. Sobre esto un ejemplo clarísimo: Wunderlist, una aplicación que empieza a sonar con fuerza desarrollada con Titanium y obteniendo de paso la multiplataforma, al ser el resultado un navegador más un wrapper simplifica mucho la distribución en cada SO -móviles incluidos- más el despliegue web unificando más la experiencia/ecosistema.

A pesar de lo mucho que mejoren los navegadores siguen siendo un medio de acceso a contenidos remotos, no locales, por más que puedan editar videos o generar gráficos impresionantes, por esto diferencio que una cosa es para un usuario en su casa (95% neto consumidor y las redes sociales como ejemplos de apps full-web) y otra cosa es el hámbito laboral, donde se genera el contenido, los datos, aquí hay otras exigencias que los navegadores al menos hoy día no cubren, y el desarrollo híbrido puede abrirnos una veta muy interesante.

Volviendo al título del post: "Web o desktop?", creo que podemos complicarla aún un poco más: Web, Desktop o Híbrido?

Java vs Ruby

Este post es absolutamente viral así que no esperen demasiados fundamentos técnicos, el tema es que lo leo y aún no lo creo, están realizando el llamado a presentar charlas para la RubyConf Uruguay 2011 y en el proceso te disparan "charlas inspiradoras que demuestren por qué ruby y el ecosistema circundante son una mejor alternativa que otras tecnologías (*ejem* Java *ejem*)." WTF??, y estos que se traen, vamos, no se porque me gasto en enojarme con estos trolls, pero es que no entiendo a que viene esto, yo mismo dije que me gustaban las comparaciones de esta herramienta vs otra, pero un palo así gratuito es que no lo veo.

Esta tendencia de atacar a Java desde la comunidad Ruby es que ese torna molesta a más no poder, es como un capricho impertinente, como viene con ideas nuevas todo lo otro esta desfasado, pasado de moda, algo que no vale la pena invertir tiempo ni esfurzo en usar o aprender.

Es verdad que Rails (que no es lo mismo) puso sobre la mesa una nueva manera de ver las cosa en esto del desarrollo web, no por nada tenemos frameworks tanto en Java (Groovy con Grails principalmente pero hay otros ) como en mi querido PHP (CakePHP creo el más representativo) toman esas ideas y la hacercan a estos lenguajes u otros, pero el universo es acotadísimo, es que si te sales del desarrollo web difícilmente alguien te mencione Ruby, todo lo contrario a por ejemplo Python, doy fé de que tengo varios compañeros  que hace años trabajan haciendo scripts de servidores y jamás hicieron una web, es más, esa es una de las cosas que me enamoraron de Python, la capacidad de ser multiuso, lo usamos para todo y el abanico de áreas donde se aplica es diverso a más no poder, unos para web con Django y otros en aplicaciones que ni siquiera tienen interfaz gráfica, y no me recuerden que PHP no es solo para web porque existe PHP-GTK, no estoy hablando de bindings aquí, me refiero a sus hambientes naturales.

Esta actitud la veo desenfocada, la gente que recién entra en esto puede llegar a tener la mala idea de que solo hay una forma cool de hacer las cosas, no se, es como que tienen que aderezar la herramienta con un toque de ideología fundamentalista, y si parece que exagero al menos no me pueden discutir que esto de enfrentarse al resto de soluciones en Ruby ya parece hábito, de puro necio me traigo un par de videos con esa onda Apple vs Microsoft y demás.

En fin, no voy a mostrar músculo pero es que no puedo evitarlo, solo hablar del mundo SOA, sobre las más de 300 JSRs, ya sé que cantidad nunca equivale a calidad pero demuestra que hay mucha gente detras de esto, mucha industria empujando este muerto a pesar de los palos en la rueda de Oracle, solo menciono que con seguridad el banco a traves del cual cobras el sueldo, la agencia de pagos donde lo gastas o el ISP que te permite leer estas líneas tienen en toda o parte de su infraestructra algunas líneas de Java, y te aseguro que no son pocas, dudo que se pueda decir lo mismo de Ruby.

Y sigo, existe algo como esa gran desconocido que es JWS en Ruby?, si aterrizamos a desktop el desarrollo multiplataforma real, no olvidemos tampoco que las apps de Android se desarrollan básicamente en Java, o las demás aplicaciones de peso pesado, solo aceptaría que viniese alguien de .NET o los dinosaurios de SAP a generar controversia, pero seguro que no un fanboy de Ruby, en fin, para el que solo tiene un martillo todo son clavos, me quedo con una frase que leí y por lo cual Ruby on Rails y esa magia, perdón: "convención por sobre configuración" aunque útil bien usada, me genera un poco de rechazo:

- No sabes lo que estás haciendo, pero funciona.

- No sabes lo que estás haciendo, y además no funciona.

No es que en Java no me haya perdido más de una vez, pero por lo menos aplica aquello de "en Java es difícil hacer las cosas mal, en Python es fácil hacerlas bien", creo que es como dice mi compañero, es fácil pegarle a Java, no tanto a Python, más si hablamos de web donde las carencias son muchas y el desarrollo generalmente pesado, lo reconozco ya que no por nada existe GWT, que si bien es fabuloso nace para facilitar la transición de desarrolladores Java a esto de la web 2.0 (cliché feo si los hay, pero nos entendemos) o por lo menos la gran mayoría de sus usuarios así lo usan.

Es que ni siquiera se comparan, el que desarrolla web difícilmente opte por Java, y el que desarrolla con Java seguramente no se meta a crear sitios, hay alternativas más baratas, simples, rápidas y creativas de hacer las cosas, y acepto que Ruby es una de las mejores, pero marearse con los aplausos creo es demasiado.

Bueno, hasta aquí llegue, si buscan fundamentos más técnicos adjunto un par de enlaces interesantes, para lo viral ya tenemos este post, ahora me es más fácil tomármelo con humor (mentira, sigo ofuscado, pero soy tolerante).

Ruby vs Java

Steve Jobs y mis sensaciones encontradas

Los que me conocen saben que me caen bastante mal los productos de Apple, su política y sobre todo la personalidad de Steve Jobs, un personaje de esos que es preferible no tener como jefe, es más, me parece patético como los desarrolladores aceptan esas condiciones lamentables a cambio de poder estar en la App Store, si si, ya lo sé, si tienes demasiados principios no se llega muy lejos en esto de la venta del software, si no me crees pregúntale a mi jefe que vendió un CRM que solo existía en el papel, por eso prefiero estar podríamos decirle en el lado ¿bueno, romántico?... no, mejor llamarle el lado oscuro de la fuerza, picando código, investigando, atento a ese cambio de versión que deja obsoleto todo lo anterior y te obliga a releer de nuevo la documentación, más difícil sí, pero mas prometedor también, imposible no dejarse atrapar, lejos de los departamentos de venta y soporte al cliente (ufffff!!, perdón, me dejé llevar).

Volviendo al tema del post, es increíble con internet lo fácil que es formar una opinión de alguien sin siquiera conocerle personalmente, mejor dicho siempre fué fácil (si no no existiría la política) y hasta natural, pero hoy tenemos info hasta de sobra, así que las posibilidades se multiplican, por eso en el caso de Jobs valoro posts como este en que opinan de primera mano, valioso para reafirmar mis convicciones de que el tipo apesta.

Ahora con la noticia de que renuncia a su puesto de CEO en Apple, y sin creerme aún los comentarios ridículos (ej:  "en la palabra genio deberia ir su foto al lado en el diccionario", otro: "estoy al borde de las lagrimas, espero que se mantenga la compañía #PapaJobs"  y este ya me superó: "Tim no decepciones a tu amigo Steve, que el dinero y el poder no te cieguen que tu mirada sea al futuro, aun tenemos la dicha de tenerlo a nuestro lado y eso ya es bastante. Que Dios te bendiga Steve Jobs"), como hay gente tan hueca que habla del tipo como si perdieran un familiar o peor?, en fin, me puse a buscar un poco de información más detallada, escuchar una charla o un discurso a ver que tanto puede decir, y aquí es donde me cambia un poco la idea que me había hecho del fulano, solo un poco quizás pero lo suficiente para volver a recordar que realmente no sabemos nada de nadie, ya sé, demasiada filosofía o la madrugada me está afectando, por eso les dejo este video y solo comento que hacía tiempo no prestaba tanta atención a un discurso.

No hagas esto

En el caso de que te haya picado la curiosidad por el mundo de los negocios en el desarrollo de software seguramente visitaste sitios de empresas conocidas para ver un poco mas de cerca de que va esto, los tipos de servicios que se ofrecen, modelos de negocio, nichos y ver en donde podemos llegar a tener alguna posibilidad en base a nuestras expectativas.

Los ejemplos buenos ya los conocemos todos, basta recordar cualquier empresa conocida, pero los malos, esos que desde el vamos no queremos parecernos ni por asomo son tanto o más interesantes, como queremos ser quizás no lo tengamos tan claro, pero estar seguros de como NO queremos ser también es vital en el proceso de visualizarnos de cara a potenciales clientes.

chantas profesionales

Precisamente es en esta línea que traigo dos ejemplos clarísimos de como en mi opinión no hacer las cosas, tanto en el planteo de la propuesta como su implementación.

Por un lado, un sitio visualmente simple pero logrado, agencia de social media, un aspecto limpio, claramente realizado por un profesional, que puede gustarnos o no, pero coherente en el planteo,  textos explicativos, descripción de servicios amena y no menos importante, tarifas a la vista, claras y sin rodeos.

Que hay de malo aquí? pues básicamente el tratar a tus potenciales clientes como idiotas, si lo que persigues es solo eso, poder atrapar un par de incautos y hacer un dinero rápido no hay problemas, eso si, largo de mi blog!.

Mirando un poco mas en profundidad empezamos a ver que la propuesta apesta y mucho, vamos, no se por donde empezar, comienzo con algunas frases:

Encontramos, mimamos, y hacemos crecer tu comunidad de clientes, el planteo típico del usuario como un producto más, el pensar que tus clientes son idiotas y se van a tragar cualquier cosa que le pongan delante, el hablar de hacer crecer una comunidad como si fuera apilar cajas en un estante, que se van a sentir atrapados por tu mensaje y convertirán en seguidores y compradores compulsivos de tu loquesea.

Somos especialistas en 2.0, y en la 3.0 si nos aprietan, bueno, definitivamente vamos mal, el peor cliché interpretado de la peor manera, obviamente dirigido a quienes lo de 2.0 y 3.0 es un concepto vago que hay que incluir como sea, aderezado por ese si nos aprietan que me da toda la pinta de que todo es conversable, incluso que me cuiden el perro el fin de semana.

Rematando la frase anterior tenemos un La vida es genial totalmente descolgado, acompañado por ese muñequito sacando la lengua con un descaro sublime, solo le falta una flecha con el texto "cagador profesional", bueno, ya rematando esta joyita: No hay monstruos aquí. Sobre todo porque contratarlos sale caro, y no agrego más nada , solo menciono este post anterior y nos entendemos, en definitiva este tipo de planteos son inmantenibles en el tiempo, no se puede confiar en que los clientes siempre serán tontos.

hay que jugársela en serio

En la otra punta tenemos el ejemplo totalmente contrario, un sitio que parece serio, la propuesta tiene valor y se intenta dejar claro una profesionalidad a toda prueba, y digo se intenta, porque lograrse.... no se logra.

Me refiero a PI, que dejando de lado el diseño, que es ese tipo de cosas que hay que dejar a los que saben, así sea un amigo que maneje Photoshop, lo que mas rescato es que no basta con ser profesionales, también hay que parecerlo.

De buenas intenciones esta lleno el camino al infierno, por lo que no importa que tanto nos explayemos en detallar nuestras capacidades, un dominio gratuito es suficiente para dinamitar nuestra imagen, nada peor que una casilla de dominio gmail, yahoo o hotmail suena tan informal para una empresa, y no hablo solo de costos, supuestamente trabajamos con Internet, ese tipo de cosas dejémoslo para las ONG's con pocos recursos y buenas intenciones, y es precisamente este aspecto el que condensa todo lo anterior: no te tires al agua si no tienes los medios mínimos adecuados, así no sea más que un dominio propio. 

Quizás suene duro, pero si estamos tratando de montar "una empresa" no podemos alojar el site en algo similar a un dominio genérico, hay que apostar en serio, si no nos lo creemos nosotros mismos menos lo creerán los potenciales clientes, sin mencionar que ese "Make a free website" lo dice todo, tampoco esos enlaces sin ton ni son a Facebook son necesarios, ya están en nuestra web, no es necesario redirigirlos a ningún lado, aquí es donde nos la jugamos a convencer al potencial cliente, no utilices la misma plantilla sosa que pusieron todos ni lo hagas más complicado de lo nescesario, pero repito: no utilizes dominios gratuitos, no utilices casillas genéricas, hoy día hay alternativas muy económicas que nos pueden dar un resultado mucho más profesional por poco dinero, si tu propio site apesta, quien garantiza mínimamente que tu trabajo no lo hará?, y si no puedes montar algo que paresca una empresa, no lo llames así entonces, ofrécete como freelance para iniciar y luego vas mejorando.

En fin, como criticar es gratis me he despachado con este par de ejemplos, no es que si no montamos un sitio rompedor de esquemas no nos va a resultar, lo que hay que hacer es un trabajo esmerado, claro, que transmita un mensaje simple, sobre esto otra muestra: la web del producto donde trabajo, a alguien le queda claro a primera vista de que se trata?, hay frases muy tentadoras, pero creo que al final abruman y no se transmite un mensaje único, simple y directo del porque elegirnos, lo que demuestra que no es un tema de recursos económicos, si la idea no esta bien transmitida no importa el diseño, no importan los efectos y botones de "me gusta", estamos perdiendo puntos desde el arranque.
Como contrapartida menciono a Little Workshop y Filament Group, un par de casos a mi parecer acertados, creo que cualquiera puede decir a la primera a que se dedican estos tipos.

Enlaces: agencia de social media, PI , Little Workshop, Filament Group

Comunicaciones unificadas, de que estamos hablando?

Ahhhh.... Unified Communications, ese tipo de palabritas que me es imposible resistir, de salir a buscar significados, propuestas, productos, en fin, deleitarse con toda esa parafernalia marketinera que nos haga sentir que ahora sí, tenemos a disposición la tecnología del futuro para entendernos.

Este es uno de esos términos tan ambiguos como prometedores y claro, hay que acercarse y ver de que se trata, de que va la cosa, y hoy más que nunca cuando esta más que claro que la eficiencia en las comunicaciones es vital para cualquier actividad productiva, bah, desde siempre para cualquier actividad diría yo, solo que ahora tenemos la pista libre, es más fácil buscarle otro sentido, unir esto con aquello y obtener algo que le de esa vuelta de tuerca que no imaginábamos.

Volviendo al termino tan vendedor de Comunicaciones Unificadas, no me voy a explayar sobre lo que es, no me gusta inventar, solo contar mis impresiones luego de una extensa lectura en paginas de productos, fabricantes y vendedores de humos varios.

Al trabajar en el desarrollo orientado a las comunicaciones VoIP los conceptos se vuelven familiares, pero se pierde un poco el foco, el de que se trata esto, y de como se puede mejorar.

Una constante que veo es la tendencia a integrar todas las vías de comunicación en un único punto central, una especie de hub de mails, chat, VoIP, fax.. y si me das tiempo te agrego capacidades de videoconferencia, SMS y una lata con una piola para hablar con el compañero de enfrente.

Amén de todo esto, a nuestra bandeja de entrada con esteroides podemos darle una patina social, otro buzzword de esos que me encantan, es el mismo planteo anterior solo que ahora le agregamos un botón de "me gusta", algo de Twitter o porque no Google+, total, mas vale que sobre a que falte, pero sobre esto me lo reservo para otra entrada :)

Esto de unificadas, si bien se refiere a una especie de concentrador de diferentes vías de comunicación, o por lo menos así lo entienden no pocas empresas, surge de la necesidad de concentrar en algún punto toda esa parafernalia de chat, mail, llamadas telefónicas..., pero no basta, no es suficiente, para mi necesitamos continuar al próximo paso: volver transparente el como para ocuparnos del que, olvidarse de que se utilizo en el camino para establecer este contacto y ocuparnos de que es sobre lo que estamos tratando.

No estoy hablando de semántica, no me refiero a que la aplicación entienda sobre que trata el hilo de datos, me refiero a que el soporte de este hilo de información sea transparente, vital si, pero no condicione la comunicación, a ver, me explico, que tal si estoy chateando y tengo que adjuntar documentos, no debería ser la aplicación lo suficientemente capaz de proporcionarme esta alternativa sin tener que salir del chat para abrir el cliente de correo, no debería ver en mi timeline un SMS entrante en medio del hilo de mensajes?, son ejemplos simples, pero recién cosas de este tipo considero que pueden ser llamadas comunicaciones unificadas.

Claro que dicho así parece fácil, solo resucitemos un Google Wave y listo, comunicación + comunicación + comunicación con un plus de trabajo colaborativo, pero creo que va un poco mas allá, no solo saber como volver un recurso en compartido, algo que sea aplicable al mail, a los SMS, a un chat, a un loquesea, sino también capaz  de abstraerme incluso de la plataforma que  utilice, sea un smartphone, un pc u otro.

Por supuesto, algo tan abstracto no puede ser sencillo, un protocolo genérico , algo como BEEP tal vez?, XMPP recargado?, agrupar recursos según prestaciones, canales mixtos predefinidos con un input/output común?, mmmmmm, nada trivial, tampoco imposible, pero clave para abstraer un canal del tipo que sea y convertirlo en solo eso, un canal mas, solo otro recurso de los disponibles, y mientras lo digo lo pienso: 

la tecnología subyacente es lo de menos, basta que sea confiable, algo de que fiarse, otro paso hacia olvidarnos de ella, es mas, si un tipo de comunicación no esta disponible que el sistema utilice otro, que decida el mejor camino por mi, solo debo saberlo y decidir si me es relevante.

Obviamente se requiere algo que pueda mostrar coherentemente este panorama, algo que me ilustre "te llame y no contestabas así que te deje un mensaje, como no estas conectado te reenvío un mail y fijate vos" y me ayude a digerirlo, ni hablar ya de si tenemos que incluir documentación, con todo el marasmo de formatos y demás, tranquilamente toda una aplicación aparte solo para eso, en ese caso con mostrar los docs como un flujo asociado y observaciones de forma organizada creo que es mas que suficiente, la comunicación hoy día ya ni por asomo se limita solo a la voz, es un flujo de datos multiformato, no nos estanquemos en el VoIP, hablamos de comunicaciones, no de comunicaciones de tal tipo.

Seguramente no menciono nada nuevo, es mas, quizás ya hay alguna aplicación que hace esto hace rato y no tengo el gusto, el resto de soluciones que por ahora solo se limitan a manejar estas vías aun así parten con ventaja, ya tienen disponibles estos canales de datos, ahora solo falta buscarle la forma de hacerlos pasar de protagonistas a mero soporte.