Salxo

Diseño y Desarrollo web al palo.

Feed

Así como podemos realizar nuestras pruebas de JS HTML y CSS con JsFiddle (http://jsfiddle.net) ahora también podes probar tus aplicaciones de NodeJS.

Runnable (http://runnable.com/)

Es una excelente opción a la hora de realizar pruebas con NodeJS ya que carga dependencias y trabaja con várias versiones de este excelente web server.

Podés acceder desde http://runnable.com/

Hasta la próxima.

 

web-components

Así como en la electrónica se utilizan componentes complejos que a su vez son formados por otros que permiten su funcionamiento, he aquí el concepto adoptado en la web.

Uno de los grandes objetivos sobre los que se están trabajado en la web son los “Web components”, o Componentes web.

Estos componentes  buscan solucionar o estandarizar widgets, controles y componentes comunes reutilizables y encapsulados, o como podría ser más claro dentro de un entorno probado en el que no pueda invadir componentes de su entorno y que su manipulación sea controlada o accedida por una api limitada teniendo como objetivo proteger la seguridad y otros aspectos del funcionamiento esperado como la aparición de ID’s duplicados u otras colisiones.

Actualmente podemos ver  estos componentes como los utilizados en el control de video que se presenta cuando utilizamos el tag <video>.

Cuatro ramas:

Los “Web components” o como lo llamaremos en esta entrada “WC” se dividen en cuatro ramas de trabajo o enfoque.

- Templates: (Plantillas)
- Shadow DOM (DOM sombra)
- Custom elements (Elemento personalizados)
- Pakaging (Empaquetado o Encapsulación).

 

Shadow DOM

Shadow DOM es un concepto que aborda la encapsulación del DOM y es implementado por medio de JavaScript lo que nos permite modificar los datos encapsulados así como su funcionamiento. Siendo uno de los elementos tratados hace poco es implementado hasta la fecha a partir de Chrome 25 por medio del prefijo “webkit”. Por ejemplo, si habilitamos desde nuestras herramientas de desarrollador en chrome, desde las configuraciónes, la opción Shadow DOM, al inspeccionar un tag <VIDEO> de html5 podemos ver que dentro del tag video se encuentra un shadow dom que contiene todos los elementos que hacen a este componente, como los botónes, volumen y demás. Por este medio se puede acceder a modificar los controles con nuestros requerimientos de presentación, entre otras cosas.

En sintesis el Shadow DOM es un DOM encapsulado que coexiste dentro del DOM padre y permite definir elementos complejos como componentes de video, entre otros, y poder tanto reutilizar estos componentes como personalizar los existentes.

 

Templates

Los templates son platillas en HTML que se completan o utilizan con un modelo o colección de datos externa. Actualmente Frameworks de JS como Ember, Knockout, y otros, lo implementan así también como se pueden encontrar sistemas de templating del lado del cliente como Mustache, Handlebars, y mas.

Estos son implementados en el navegador por medio de, lo que vimos anteriormete, el Shadow DOM.

 

Pakaging

Estas son las técnicas y métodos que se utilizan para brindar privacidad, protección y abstracción a los controles, y componentes tanto utilizados de manera standard en los navegadores como los definidos por nosotros para el uso particular y común en nuestra aplicación. Uno de los principales conceptos de la POO o OOP (Programación orientada a objetos)

 

Custom elements

Para comenzar aclaremos a que nos referimos en primer lugar como elements o elementos. Los elementos agrupan entre otro, los tags: inputs, video, audio y demás elementos que nos brindan no solo una presentación, sino que además controles y funcionamientos estándar para tareas específicas dentro la interfaz y son comunes y transversales sobre toda aplicación web. Hoy ampliados en funcionamiento así también como nuevos disponibles como video, audio y los tipos email y number por medio de HTML5.

Por otro lado, la idea es poder definir o extender el lenguaje base con nuestros propios componentes para el uso constante o estándar dentro de nuestra aplicación o sitio (Creo que el concepto de sitio web solo define una landing comercial sin mayor funcionalidad que una presentación visual, hoy por hoy, algo que salga de esto se convierte en aplicación, pero es solo un concepto.). Para esto se plantea en conjunto con el concepto de template y packaging (por medio del shadow dom), la definición de estos en una sola instancia y la reutilización. Un ejemplo podría ser la necesidad de utilizar “Spiners” en nuestra interfaz y por medio de esta característica lo haríamos una sola vez y lo llamaríamos tantas veces como lo necesitemos.

Link al video que muestra este ejemplo (Ingles): http://www.youtube.com/watch?v=pQOuHNm5seY

Pronto publicaré un ejemplo mostrando las utilizaciones que les podemos dar a este maravilloso concepto de Componente Web, de más está que cada uno podrá ver el poder de este nuevo concepto.

Hasta la próxima.

Links interesantes:

Custom elementshttps://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
Ejemplo de uso custom elements: http://blogs.adobe.com/cantrell/archives/2012/03/a-short-simple-video-explaining-the-shadow-dom-and-web-components.html
Especificación de la W3C sobre Shadow DOMhttp://www.w3.org/TR/shadow-dom/

 

Actualización:  (13/03/2013)
Primer draft de Web Components W3C: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html

 

 

En una entrada anterior hable sobre la diferencia del RWD y el AWD, ahora quería comentar un poco sobre una técnica llamada RESS, del ingles Responsive Desing + Server Side Components o Diseño web responsivo del con componentes del lado del servidor.

¿De que se trata RESS?

Ress es una técnica que consta de sumar al diseño “Responsive” optimizaciónes del lado del servidor. Esto se realiza, por ejemplo, detectando el dispositivo visitante y con una librería, como puede ser Wurlf, y prestar contenido perfilado a las capacidades del dispositivo.

Un ejemplo de uso:

Un caso de uso que es, a mi entender, uno de los mas jugosos es: Utilizando los datos del tamaño de pantalla del cliente, y con un servicio preparado para esto, solicitar las imágenes con un tamaño especifico y así optimizar el peso de las transacciones. Aquí es donde entra esto que decía antes de lo “jugoso”. En dispositivos móviles, tanto de bajos recursos (a nivel hardware) como en conexión (En Argentina el 3g /4g apesta) esto es crucial para que el sitio cargue rápido y con esto brindar una experiencia positiva al visitante/cliente.

Otro caso podría ser la inclusión o no, de elementos de terceros  ( como los plugins de Twitter o Facebook, Google+, etc…), en el caso de una navegación casual es muchas veces irrelevante colocar un plugin social ya que, en primer lugar, no se le dará uso y por consiguiente es una carga innecesaria, y hasta podría frustrar a nuestro visitante y perder lealtad o peor, una venta.

Con estos casos que te dejo podés comenzar , con poco, subir un nivel a la calidad de experiencia que tiene tus visitantes.

Hasta la próxima.

 

 

Es una afirmación un tanto jugada me podrían decir, pero según los números que se presentaron en el análisis por parte de la gente de EectricPulp se puede ver claramente un aumento en las conversiones sobre un sitio de e-commerce al utilizar el patrón (o técnica) RWD. Veamos un poco:

Este análisis se llevo a cabo durante 6 semanas en total variando en un periodo de  3 semanas entre acceso responsive y no responsive, ¿Que dicen los números?

iPhone/iPod:

TASA DE CONVERSIÓN: + 65.71% ARRIBA
TRANSACCIONES: + 112.50% ARRIBA
RENOVACIONES: + 101.25% ARRIBA

Equipos Android:

TASA DE CONVERSIÓN: + 407.32% ARRIBA
TRANSACCIONES: + 333.33% ARRIBA
RENOVACIONES: + 591.42% ARRIBA

Equipos no Mobiles:

TASA DE CONVERSIÓN: + 20.30% ARRIBA
TRANSACCIONES: + 71.11% ARRIBA
RENOVACIONES: + 41.13% ARRIBA

Nota completa (inglés): http://electricpulp.com/notes/more-on-apples-mobile-optimization-in-ecommerce/

Es muy claro el beneficio de contar con un sitio “responsivo”. Cada vez tenemos menos tiempo para realizar nuestras compras y es visible que, permitir el acceso a los productos que queremos adquirir a diario, nos va a forzar una tendencia sobre otras opciones tradicionales.

La realidad Argentina:

En Argentina de todas formas contamos con muy pocos sitio que nos permitan acceder de forma móvil a realizar nuestras transacciones. Actualmente los sitios de los super-merados mas grandes no cuentan, siquiera con su sitio de presentación Responsive, lo cual  a mi opinión, no está bien. Creo por mi parte que no lo hacen, debido a que miden sus transacciones online y al ver números que no son relevantes no se “largan” a hacerlo. Aquí es donde debemos comprender las diferencias de públicos y contextos: una persona que compra online sentado en su casa quizás tiene hasta el tiempo de sentarse en su casa y elegir cuidadosamente (mas allá de la poca usabilidad con la que cuentan estos sitios) y tal vez, hasta decide ir hasta la sucursal y de paso despabilarse un poco. No es así el tiempo que tiene una persona que viaja de su casa al trabajo en transporte publico, y tiene esas horas en viaje para adelantar las tareas, y luego, al llegar a su casa recibir el pedido cómodamente. Falta mucha conciencia y estudio del área de la !experiencia de usuario” tanto online como offline, y el gran impacto que tiene esto sobre su lealtad a la marca.

Cada vez tenemos más puntos de entradas  sobre nuestros clientes, tanto potenciales como reales. Aprovechemos el diseño Responsive.

Hasta la próxima.

Diseño web Responsivo y Diseño web Adaptado

responsive-dispositivos
Diseño web Responsivo y Diseño web Adaptado (Responsive web design & Adaptive web Design)

Tendencias, tendencias, formas, frameworks, HTML5, CSS3 y cuantas mas cosas no dejan de dar vuelta por dios!

Bueh, hoy aquí un poco de pasar en blanco esto del Diseño web Adaptado y la diferencias con el Diseño web Responsivo. Como arranque la principal diferencia parte del simple hecho de modificar el layout del proyecto según el dispositivo o estar “elástico al cambio”

Diseño web Adaptado (Adaptive web desing) o elasticamente adaptado por naturaleza:

El AWD (Adaptive Web Design) trata de, tener un layout preparado sin grillas ni mucho menos jugando con los tamaños de ancho, altos en porcentajes y demás medidas relativas al dispositivo, combinada con técnicas de lo que se llama “progressive enhancement” (o no).

Diseño web responsivo (Responsive web design)  o lo acomodo según el tamaño en el cliente:

Es RWD (Responsive web design) categoriza dentro de las técnicas que utilizamos por medio de, principalmente, CSS3 y sus MediaQuerys entre alguna que otra técnica JS como Modernizr que .mediante BreakPoints y capacidades del dispositivo, cambiamos la forma en la que se presentan los diferentes contenedores.

Ah listo, ahora entiendo.

Por mi parte opino que este donde quieran que esté, fuera de lo académico, ambas técnicas tienen un buen jugo que dar a nuestros sitios y aplicaciones y está en cada desarrollador utilizarla de forma inteligente para cada proyecto y por ende cliente objetivo que debe ser siempre nuestro punto guía.

¿Has utilizado estas técnicas en tus proyectos? ¿Cuales?

A lo largo de nuestro camino como Desarrolladores o Diseñadores Web, vamos viendo herramientas, plugins, frameworks, que nos van ayudando a desarrollar de manera ágil y a veces más rápida soluciones para nosotros o nuestros clientes. Ahora bien, siempre pasa que intentamos por ejemplo, realizar una animación y decimos, ¿Como se llama ese framework para animar SVG? y es entonces cuando perdemos muucho tiempo buscando nuevamente eso que estamos necesitando. Esto pasa todo el tiempo, y para esto he aquí, “JSDB.io“. Una página que presenta frameworks, herramientas, plugins JS Javascript organizados por categorías con la información de GitHub de cada proyecto: Estrellas, Rating, Forks, Descripción, Similares y más.

 

URL de la herramienta: JSDB.io

 

Dentro de los cambios que se vinieron con la oleada de HTML5 y CSS3 están las nuevas apis disponibles para manipular con JavaScript una muy interesante es “Visibility API” una API que nos permitirá saber cuando se está viendo la pestaña o ventana que tiene cargada nuestra aplicación.
Esto es de mucha utilidad a la hora de notificar algo en particular o tiempos de refresco y demás.

Especificación: http://www.w3.org/TR/page-visibility/
Implementación por MS: http://ie.microsoft.com/testdrive/Performance/PageVisibility/Default.html

Dictale al JavaScript: Speech JavaScript API

EL primero de octubre se libero el primer draft sobre Speech JavaScript API.

Esta API nos permitiría desarrollar aplicaciones que le brinden una nueva forma accesar datos a los usuarios a través de su voz, tanto como convertir texto en audio (TTS: Text to Speech).

les dejo el link al draft: http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html

 

Si les interésa reconocer texto y convertirlo a audio (TTS), la gente de Mozilla tiene un script (speak.js): https://hacks.mozilla.org/2011/08/speak-js-text-to-speech-on-the-web/

 

Pronto más noticias de HTML5, CSS3, y nuevas implementaciones de JavaScript