Utilicemos PushState()

Querido  pushState( )


Para conseguir la mejor experiencia de navegación posible uno de los recursos que utilizamos es la precarga o caché de diferentes secciones de nuestras web. Con esto conseguimos que la transición entre dichas secciones no conlleve una recarga en el navegador, sino que aparezca y oculte de forma inmediata.
De igual forma, utilizamos AJAX allá donde lo consideramos necesario para reducir en lo máximo posible los tiempos de espera del usuario.
ajax2
Todo esto es muy bonito, y se lleva utilizando desde hace bastantes años, son técnicas básicas que cualquier desarrollador web habrá utilizado en infinidad de ocasiones pero conlleva un problema inherente: nuestros contenidos cambian pero nuestra url en la barra del navegador permanece inalterada.
¿Cuál es el problema entonces? Pues sencillamente que esos contenidos dinámicos serán inaccesibles desde una url determinada, de tal forma que para llegar a ellos tendremos que ejecutar la lógica necesaria en nuestra aplicación ya sea un botón, enlace o cualquier forma de evento que se nos haya ocurrido siendo, por tanto, imposible compartir directamente esa sección que tanto nos interesa, o incluso siendo invisible para los motores de indexación de moda (aka Google). Esto rompe con la filosofía de la web, pues con una misma URL tendremos diferentes contenidos, según las acciones que llevemos a cabo. Debemos intentar reducir al mínimo este comportamiento.
Afortunadamente, y para ello es este post, tenemos una solución bastante elegante y poco intrusiva: El método pushState().
PushState() admite 3 parámetros, el primero es un objeto JS que podemos asociar en el historial con los datos que nos interesen, el segundo es el título que queremos poner en nuestra página (de momento no lo acepta casi ningún navegador, pero siempre podemos utilizar document.title), y el tercero sería la propia URL que queremos que aparezca en nuestro navegador. Con la URL bastaría si no necesitamos asociar datos a cada paso en el historial.
push
De esta forma, asociando pushState a nuestra carga de datos AJAX, o cualquier cambio dinámico de contenido, podemos establecer una URL diferente para cada caso. Obviamente, debemos de tratar esas url y mostrar al usuario el contenido dinámico apropiado en caso de que acceda directamente desde la URL que hemos generado.
Para muestra un botón, podéis ver un ejemplo en nuestra web comercial de TwinPush, en la sección características. Podemos cambiar entre las diferentes ‘features‘ sin carga de datos entre ellas, sin embargo, la URL si que está cambiando por si necesitamos compartir una característica determinada.
Podremos acompañar al uso de pushState con el evento onpopState. Este evento detecta un cambio en nuestro historial (por ejemplo al presionar el botón ‘Back’ en nuestro navegador). Con este evento, además, obtendremos una copia del objeto que utilizamos en el pushState (si es que se lo llegamos a indicar). Este evento es muy útil para cuando queremos navegar hacia atrás o adelante en nuestro historial generado por pushStates.
Con estas herramientas ya no tenemos excusa para que nuestro contenido dinámico no genere sus propias URL, y de esta forma mejorar la accesibilidad de nuestra web.

TRELLO en mi trabajo, como emplearlo para mejorar mi proyecto.

Hace un tiempo ya, y realmente, el día que salió, yo ya tenía una cuenta de Trello. Era simple, era bonito, era rápido, pero no veía el gran poder que tenía. Es porque, como muchas cosas, hay que saber utilizarlas.
Hoy es para mi una herramienta fundamental en mi organización (personal y laboral) y me ha vuelto más productivo y ha evitado muchos de esos momentos de “¿y ahora qué?” o “¿en qué estaba?“. Voy a compartirles el como para que sepan cómo lo hago yo, y espero comentarios de cómo lo hacen ustedes. 

Trello por default

Trello se compone de boards (pizarras) que a su vez se componen lists (listas), que a su vez contienencards (tarjetas).
Cuando crean un board por primera vez, verán esto como su contenido.
Trello default lists
(Puede que se vea distinto si su resolución de pantalla es menor, en ese caso pasará al modo mobile.)
El flujo ya es bastante apropiado en la forma en la que se presenta, y es ideal para grandes grupos de gente (ah, es multiusuario). Básicamente, las cosas se van dando de alta en la lista To Do, al momento en que comienzan a trabajarse, se mueven a Doing, y al momento de terminarlas se pasan a Done.

Preguntas respondidas

La simple disposición de tareas de esta forma ayuda a responder muchas preguntas.
Cuando las cosas están en To Do es porque es importante ver cuáles son todas las cosas pendientes. Responde preguntas como “terminaremos para hoy/mañana?” o “cuando termines con esto estás libre?“.
La lista de Doing ayuda a ver qué progreso se está haciendo. Responde preguntas como “En qué está trabajando José?” o “Qué estaba haciendo yo?” (especialmente útil para los que lidian mucho con interrupciones).
La lista de Done ayuda a ver qué se terminó. ¿Qué sentido tiene esa lista? Ayuda a responder preguntas como “¿Qué porcentaje de tareas terminamos?“, “¿Avanzamos mucho?“, “¿Qué está presente en esta versión?“.

Mi variante: el día a día

Mis cambios a ese esquema por default no han sido radicalmente distintos, pero lo suficiente como para mencionar. Este es el caso de mi trabajo, tengo distintos esquemas para distintos tipos de proyectos personales (y creo que esa es una de las cosas que hace a esta herramienta tán versátil). Estas son mis listas y para qué se usan:
To Do: Igual que siempre este es el listado de todo lo que se tiene que hacer, o que algún día tiene que ser resuelto. Puede ser mañana, puede ser la semana entrante, puede ser “algún día” indefinido.
Get Done Today: Al principio del día, luego de checkear mis correos y verificar qué cosas tengo pendientes que no sabía antes, elijo desde To Do un listado de ítems que obligatoriamente tengo que terminar el día de hoy. Puede basarse en prioridad, en tiempo disponible, en urgencias, en la dirección del viento. La forma de elegirlas no importa, lo que importa es que esas tareas son mi compromiso del día. Me sirve también para reportar en nuestra scrum meeting qué es lo que voy a estar haciendo.
Doing right now: Como su nombre lo dice, el listado de cosas que estoy haciendo ahora mismo. Si no tengo nada acá, probablemente esté almorzando. Si tengo más de tres tarjetas aquí, seguramente algo saldrá mal. Cuando me llaman por teléfono, me buscan en la oficina o me interrumpe un email, este es el lugar al que vuelvo a mirar y resumo mis tareas.
Waiting for feedback: Este es el listado de cosas que comencé pero estoy bloqueado y requiero que alguien más intervenga. Es porque la tarea depende de alguien más o porque estoy esperando respuesta de alguien para poder continuar. Siempre les agrego un comentario a esas tarjetas para poder leer cuál fue la última vez que la actualicé y para saber qué estoy esperando que me respondan o hagan. Puede que una vez que me respondan las tarjetas se muevan de aquí a To Do, o, si tengo suerte, a Done.
Done: Nuevamente, aquí es donde vienen a morir las cosas que ya hice. Mantengo este listado hasta el fin del día, en donde lleno mis timesheets (mi empresa requiere que llene un listado de qué actividades realicé cada día). Las tarjetas me ayudan a recordar, y el tener que limpiar esa lista me hace recordar llenar el timesheet.
Este es un ejemplo con mi día de hoy (exitosamente cerrando la semana):
My Work Today in Trello
Probablemente lean mis ítems y no entiendan en qué estoy trabajando, porque los títulos no son muy explicativos. Ese es otro beneficio: no tienen que serlo. Sólo tienen que decir lo suficiente como para que yo recuerde de qué se trataba todo. Si necesito más detalles uso los comentarios o las descripciones de las tarjetas (que, dicho sea de paso, soporta Markdown). Si necesito varios puntos intermedios agrego una checklist (como el primer item en la imagen), y es todo a gusto.
Espero que esto haya sido útil para quién lo lea. Si tienen sugerencias, estoy encantado de oírlas, sería muy útil para mi también aprender de alguien que sepa organizarse mejor.

Detectar dispositivo movil / Mobile device detection Javascript

Detectar si nos visitan desde un aplicativo movil 

creamos detected_movil.js y pegamos lo siguiente :


var esMovil = {
    Android: function() {
        return navigator.userAgent.match(/Android/i);
    },
    BlackBerry: function() {
        return navigator.userAgent.match(/BlackBerry/i);
    },
    iOS: function() {
        return navigator.userAgent.match(/iPhone|iPad|iPod/i);
    },
    Opera: function() {
        return navigator.userAgent.match(/Opera Mini/i);
    },
    Windows: function() {
        return navigator.userAgent.match(/IEMobile/i);
    },
  otro: function() {
    return navigator.userAgent.match(/Mobile/i);
  },
    cualquiera: function() {
        dato = esMovil.Android() || esMovil.BlackBerry() || esMovil.iOS() || esMovil.Opera() || esMovil.Windows() || esMovil.otro();
        return dato;
    }
};


en el html que deseamos detectar lo especificado añadimos el siguiente codigo js:

<script type='text/javascript' src='js/detected_movil.js'></script>
<script>
$(document).ready(function() {

    if (esMovil.cualquiera()) {
    //acciones si es movil
}
</script>

CommentFB