Etiqueta: webdesign

  • Upload A File With HTML5 / Subir un archivo con HTML5

    Upload A File With HTML5 (XMLHttpRequest)

    Upload A File With HTML5 / Subir un archivo con HTML5

    The XMLHttpRequest object

    The XMLHttpRequest object has been updated several times since was defined as the WHATWG’s HTML effort using Microsoft technology; then we had the original XMLHttpRequest Level 1 specification as part of W3C, we also had the XMLHttpRequest Level 2 updated specification, and now we have the last version of this object known as XMLHttpRequest Living Specification. We can summarize its advantages in the following points:

    • Allows upload and download files as stream bytes, large binaries (BLOBs) or data forms
    • It has event handlers for progress, errors, abortion, start, and end of operations
    • Cross-domain capabilities (CORS)
    • New type for JSON responses
    • Is a fundamental part of the HTML5 File API specification

    It’s important to emphasize that before HTML5 and the latest versions of XMLHttpRequest object it was required to resort to server-side technology in order to able to perform an uploading file operation, that is, it wasn’t possible to upload a file natively from the client side. Technologies as AJAX and Flash did their own effort but with serious limitations, so XMLHttpRequest comes to cover this old problem in a big way. There are other additional features that come with XMLHttpRequest, if you want to know more you can resort to the official specification.

    Starting

    The first thing we’ll do is to define the user interface for this small implementation starting with the HTML tags, the code is very simple and only includes some form elements, and some div tags that are only used to give a better presentation using CSS3. I won’t analyze in this post anything related to the used cascade style sheets since is not something really necessary for the operation of this example.

    <!DOCTYPE html>
    <html>
        <head>
            <title>Upload File</title>
            <meta charset="iso-8859-1" />
        </head>
        <body>
        <div id="wrap">
           <div class="field">
               <ul class="options">
                  <li><input type="file" id="myfile" name="myfile" class="rm-input" onchange="selectedFile();"/></li>
                  <li><div id="fileSize"></div></li>
                  <li><div id="fileType"></div></li>
                  <li><input type="button" value="Subir Archivo" onClick="uploadFile()" class="rm-button" /></li>
               </ul>
           </div>
           <progress id="progressBar" value="0" max="100" class="rm-progress"></progress>
           <div id="percentageCalc"></div>
        </div>
        </body>
    </html>
    The previous code explains itself, but let’s summarize what is in there:
    • A file-type input which will be used to select the file to be uploaded
    • A div which will be used to print the size of the selected file
    • A div which will be used to print the MIME type of the selected file
    • A button which will fire the uploading process for the selected file
    • A progress bar to indicate the uploading process progress of the selected file
    • Finally, a div where the progress will be shown in a percentage format

    The selectedFile() function

    Each time you select a file using the file element, you also trigger the onchange event which calls the selectedFile() function. In this function very interesting things happen, to start, a reference to a file array instantiated by the HTML5 object FileList is done, the objects that we get as members of FileList are File objects. In this case, we’ll get the size and type properties from the gotten File object.
    Using the information provided by the size property, the size of the selected file is calculated and shown in megabytes or kilobytes within the function. With the type property, the MIME type of the selected files is gotten and showed in the corresponding div.
    function selectedFile() {
    var archivoSeleccionado = document.getElementById("myfile");
    var file = archivoSeleccionado.files[0];
       if (file) {
           var fileSize = 0;
           if (file.size > 1048576)
              fileSize = (Math.round(file.size * 100 / 1048576) / 100).toString() + ' MB';
           else
              fileSize = (Math.round(file.size * 100 / 1024) / 100).toString() + ' Kb';
    
           var divfileSize = document.getElementById('fileSize');
           var divfileType = document.getElementById('fileType');
           divfileSize.innerHTML = 'Tamaño: ' + fileSize;
           divfileType.innerHTML = 'Tipo: ' + file.type;
    
        }
    }

    The uploadFile() function

    Esta es la función que hace un mayor uso de las nuevas posibilidades de XMLHttpRequest , y es la que se encargará de disparar el proceso principal del lado cliente.

    function uploadFile(){
     //var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";
     var url = "/ReadMoveWebSite/UploadMinimal.aspx";
     var archivoSeleccionado = document.getElementById("myfile");
     var file = archivoSeleccionado.files[0];
     var fd = new FormData();
     fd.append("archivo", file);
     var xmlHTTP = new XMLHttpRequest();
     //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);
     xmlHTTP.upload.addEventListener("progress", progressFunction, false);
     xmlHTTP.addEventListener("load", transferCompleteFunction, false);
     xmlHTTP.addEventListener("error", uploadFailed, false);
     xmlHTTP.addEventListener("abort", uploadCanceled, false);
     xmlHTTP.open("POST", url, true);
     //xmlHTTP.setRequestHeader('book_id','10');
     xmlHTTP.send(fd);
    }
    At the beginning, we have the variable url that we’ll use to indicate where is the page o web service which is going to receive the request from this page to do the proper process on server side. Immediately like in the selectedFile() function, a reference to the gotten File object member is also done.
    In the fourth line, there is something new and very useful, that is the FormData object, this object allows to instantiate a web form via JavaScript, that is, is like you put an HTML form using tags, or you can refer to an already existing one assigning it to a FormData object. No doubt this is really helpful since means now you can create a web form y alter the sending values dynamically. To append values to, either instantiated or referenced web form with FormData, use the append(file, object) method, this way in the fifth line our File object is added with the file name.
    This is the code of the function that covers what was just stated:
    //var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";
    var url = "/ReadMoveWebSite/UploadMinimal.aspx";
    var archivoSeleccionado = document.getElementById("myfile");
    var file = archivoSeleccionado.files[0];
    var fd = new FormData();
    fd.append("archivo", file);

    Event handlers

    Continuing with the rest of the function, we can observe that the XMLHttpRequest object is finally instantiated and is assigned to the xmlHTTP variable, and then we proceed to the next novelty, I mean the possibility of creating new events which are part of XMLHttpRequest thanks to the upload object. The added events for this particular case are:
    • loadstart. Is triggered when the uploading file process initiates.
    • progress. Is triggered each time there is an advance in the file uploading process.
    • load. Is triggered when the transfer is complete successfully.
    • error. Is triggered when the transfer fails
    • abort. Is triggered when the user/developer interrupts the process.
    These aren’t the only available events, check the official specification for more information.
    The event handlers are declared in the following code:
    var xmlHTTP= new XMLHttpRequest();
    //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);
    xmlHTTP.upload.addEventListener("progress", progressFunction, false);
    xmlHTTP.addEventListener("load", transferCompleteFunction, false);
    xmlHTTP.addEventListener("error", uploadFailed, false);
    xmlHTTP.addEventListener("abort", uploadCanceled, false);

    The triggered events functions are the following:

    function progressFunction(evt){
        var progressBar = document.getElementById("progressBar");
        var percentageDiv = document.getElementById("percentageCalc");
        if (evt.lengthComputable) {
            progressBar.max = evt.total;
            progressBar.value = evt.loaded;
            percentageDiv.innerHTML = Math.round(evt.loaded / evt.total * 100) + "%";
        }
    }
     
    function loadStartFunction(evt){
        alert('Comenzando a subir el archivo');
    }
     
    function transferCompleteFunction(evt){
        alert('Transferencia completa');
        var progressBar = document.getElementById("progressBar");
        var percentageDiv = document.getElementById("percentageCalc");
        progressBar.value = 100;
        percentageDiv.innerHTML = "100%";
    }
     
    function uploadFailed(evt) {
        alert("Hubo un error al subir el archivo.");
    }
     
    function uploadCanceled(evt) {
        alert("La operación se canceló o la conexión fue interrunpida.");
    }

    ProgressFunction() updates the progress bar and percentage which indicate in a graphical and numerical way the process progress, the rest of the functions only display the proper message for each case.

    Commented code

    If you have observed the code you probably noticed some commented lines, this is because this is just the base code to create something a little bit more complex, but I decided to leave those lines because maybe can be useful for someone:

    //var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";

    The previous line of code is a call to a .Net HTTP service instead of a page. Here is where you should call your own server-side implementation.

    //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);

    This line calls a function that shows a message when the process starts. I commented this line after I executed the code several times because was annoying.

    The completo code

    This is how the complete implementation of the code looks:

    <!DOCTYPE html>
    <html>
        <head>
            <title>Upload File</title>
            <meta charset="iso-8859-1" />
                                        <link rel="stylesheet" type="text/css" href="estilosUploadFile.css" />
            <script type="text/javascript">
     
                  function selectedFile() {
                    var archivoSeleccionado = document.getElementById("myfile");
                    var file = archivoSeleccionado.files[0];
                    if (file) {
                        var fileSize = 0;
                        if (file.size > 1048576)
                            fileSize = (Math.round(file.size * 100 / 1048576) / 100).toString() + ' MB';
                        else
                            fileSize = (Math.round(file.size * 100 / 1024) / 100).toString() + ' Kb';
     
                        var divfileSize = document.getElementById('fileSize');
                        var divfileType = document.getElementById('fileType');
                        divfileSize.innerHTML = 'Tamaño: ' + fileSize;
                        divfileType.innerHTML = 'Tipo: ' + file.type;
     
                    }
                  }     
     
                function uploadFile(){
                    //var url = "http://localhost/ReadMoveWebServices/WSUploadFile.asmx?op=UploadFile";
                    var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";
                    var archivoSeleccionado = document.getElementById("myfile");
                    var file = archivoSeleccionado.files[0];
                    var fd = new FormData();
                    fd.append("archivo", file);
                    var xmlHTTP= new XMLHttpRequest();
                    //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);
                    xmlHTTP.upload.addEventListener("progress", progressFunction, false);
                    xmlHTTP.addEventListener("load", transferCompleteFunction, false);
                    xmlHTTP.addEventListener("error", uploadFailed, false);
                    xmlHTTP.addEventListener("abort", uploadCanceled, false);
                    xmlHTTP.open("POST", url, true);
                    //xmlHTTP.setRequestHeader('book_id','10');
                    xmlHTTP.send(fd);
                }       
     
                function progressFunction(evt){
                    var progressBar = document.getElementById("progressBar");
                    var percentageDiv = document.getElementById("percentageCalc");
                    if (evt.lengthComputable) {
                        progressBar.max = evt.total;
                        progressBar.value = evt.loaded;
                        percentageDiv.innerHTML = Math.round(evt.loaded / evt.total * 100) + "%";
                    }
                }
     
                function loadStartFunction(evt){
                    alert('Comenzando a subir el archivo');
                }
                function transferCompleteFunction(evt){
                    alert('Transferencia completa');
                    var progressBar = document.getElementById("progressBar");
                    var percentageDiv = document.getElementById("percentageCalc");
                    progressBar.value = 100;
                    percentageDiv.innerHTML = "100%";
                }   
     
                function uploadFailed(evt) {
                    alert("Hubo un error al subir el archivo.");
                }
     
                function uploadCanceled(evt) {
                    alert("La operación se canceló o la conexión fue interrunpida.");
                }
     
            </script>
        </head>
        <body>
            <div id="wrap">
                <div class="field">
                    <ul class="options">
                        <li>
                            <input type="file" id="myfile" name="myfile" class="rm-input" onchange="selectedFile();"/>
                        </li>
                        <li>
                            <div id="fileSize"></div></li>
                        <li>
                            <div id="fileType"></div></li>
                        <li>
                            <input type="button" value="Subir Archivo" onClick="uploadFile()" class="rm-button" /></li>
                    </ul>
                </div>
                <progress id="progressBar" value="0" max="100" class="rm-progress"></progress>
                <div id="percentageCalc"></div>
            </div>
        </body>
    </html>

    I’m not describing the CSS3 code because is irrelevant in terms of functionality, but I share an image that shows how it looks the implementation in the browser and the link to the CSS3 estilosUploadFile.zip.

    I’m also sharing the original HTTP service that I used to test this example -the server-side code, backend file or any name that you prefer 😃- but this won’t be very useful for you unless you use the exact same stack that I was using at the moment- in other words, if you are the kind of person who just wants to copy and paste….hehehe well….maybe you’re not ready for this yet. Here is the file WSUploadFile.zip

    Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve).

    This is all for now folks, I hope this can be useful for you.

    Here some books that can help you in your HTML5 journey:

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    2 Comments
  • gamification o gamificación

    Gamification o Gamificación

    Jugando mientras trabaja, estudia, ejercita o usa la web

    Aquellos que hemos sido o somos gamers (personas que gusta de los juegos y/o video juegos) sabemos que la idea o concepto de gamificaction (en sus aún más feas traducciones al español: gamificación, ludificación, juguetización o jueguización) ha andado rondando por siempre (unas 3 décadas). Recordemos frases viejísimas como: !aprende jugando!, ¡adelgace mientras se divierte!; si alguien es de México y de mis años recordará aquellos clásicos comerciales con la frase: ¡Con juguetes Mi Alegría…aprendemos…y jugamos! (sí, el tono de canción en su mente es inevitable si sabe de que hablo). Ahora, si bien el concepto es viejo, el término se acuñó gracias a un programador llamado Nick Pelling en 2002, pero en la realidad el concepto ha comenzado a atraer la atención tan solo en años recientes.

    Últimamente me he encontrado con mucha gente que utiliza términos deslumbrantes como mecánica de juego, dinámica de juego o pretende establecer como algo complejo y laborioso la implementación del concepto, confundiendo la idea básica de gamification o gamificación con complejas campañas tecnológicas de marketing y big data. Lo anterior puede ser verdad y se pueden crear sofisticadas implementaciones de gamification, pero basado en mi experiencia involucrado en equipos desarrollo multimedia desde 1998, puedo decir que mucho sobre aplicar gamification es solo sentido común.

    Sin ser o pretender ser un experto en gamification, a continuación le comparto algunas ideas, términos y aproximaciones que he aprendido con el tiempo:

    ¿Qué es gamification?

    Hay montones de sitios donde puede obtener buenas definiciones sobre lo que es gamification (ludificación, juguetización o jueguización), pero para ahorrar el viaje a Wikipedia le traduzco lo que dice la misma en su sitio en inglés:

    Gamification es la aplicación de elementos del diseño y principios para juegos en un contexto que no es de juego. Gamification comúnmente emplea los elementos que se utilizan en el diseño de juegos en los denominados  non-game contexts en un intento de mejorar la participación de los usuarios, productividad de organización,  aprendizaje, contratación y evaluación de empleados, facilidad de uso y la utilidad de sistemas, ejercicio físico, violaciónes de tráfico, apatía de votantes, entre otros. Una revisión de  investigación sobre gamification muestra que la mayoría de los estudios sobre gamification encuentran efectos positivos en su implementación. Sin embargo, existen diferencias individuales y contextuales.

    ¿Entendió eso? Básicamente significa, hacer una tarea más interesante adoptando la lógica de un juego. La manera más simple sería otorgando alguna especie de premio por hacer alguna tarea. El premio puede ser tan obvio como un trofeo o tan vago y subjetivo como simplemente buscar ofrecer diversión mientras se hace una tarea definida. Pero desde luego hay mucho más que se puede hacer, especialmente cuando el comportamiento humano es considerado.

    Pero para cumplir con el cliché, aquí mi definición personal:

    Gamification es aplicar la metáfora del juego a tareas comunes u obligatorias para influenciar el comportamiento, dar mayor motivación e incrementar el involucramiento, la preferencia o la lealtad.

    ¿Los videojuegos sirven de algo?

    Durante algunos años fui jugador de World of Warcraft, un video juego muy popular con millones de usuarios, el cual me parece que es un gran ejemplo de cómo estos juegos se pueden relacionar con el mundo real. Dentro de World of Warcraft uno de los objetivos es hacer dinero. Este dinero se puede obtener de varias maneras, pero la mayor parte es haciendo quests (misiones). Como resultado de resolver las misiones se obtiene dinero, el cual el jugador utiliza para obtener diferentes cosas como comprar ropa, armas, materiales, mejoras, información para nuevas misiones, etc. (¿le suena esto familiar?), esto es lo básico de cualquier negocio y parte importante de la vida. Día con día los jugadores de World of Warcraft se la pasan fabricando bienes, ofreciendo servicios y cumpliendo misiones. En el mundo real hacemos lo mismo, ganamos dinero por obtener determinado logro; gastamos ese dinero en comprar nuevas cosas o lo invertimos en algo que nos permita ganar más dinero o hacer algo de manera más eficiente o cómoda.

    Una pregunta válida sería ¿por qué estos jugadores están tan dispuestos a pasar tanto tiempo haciendo lo que bien podrían hacer en la vida real? La respuesta es fácil: porque es divertido.

    Adoptando la idea

    Es importante aclarar en este punto que no todo es acerca de video juegos, no veremos en futuro inmediato a alguien deseoso de jugar el último juego de Microsoft Project o de Word (aunque nunca se sabe 😉 ). Lo que estamos intentando hacer es tomar ideas de los juegos e insertarlos en alguna tarea de rutina, para que dicha tarea no tenga que ser aburrida hasta la muerte.

    Con todo lo anterior en mente tengo que ser honesto, a pesar de la relativamente reciente popularidad de la idea de gamification, no todo el mundo sabe lo que es, no todos están interesados, pareciera que para llegar a escuchar y a comprender el término se requiere de algo de curiosidad, ganas de saber lo que está en boga o simplemente tener un poco de geekness. Todo esto hace que vender la idea en una organización no sea tan fácil como pudiera parecer (por lo menos no acá en el tercer mundo). Recientemente participé en un proyecto donde le solicitaron al equipo del cual formaba parte, proponer ideas “innovadoras” (otro término sobrevendido) para mejorar la propuesta tecnológica de una organización, como parte de esto eventualmente propuse la idea de incorporar alguna estrategia inicial y modesta de gamification dando algunos ejemplos con detalle general pero concreto, no como algo precisamente “innovador” si no como algo que únicamente pretendía poner “al día” la propuesta tecnológica implementada al momento. Sorprendentemente aunque la organización con la que trabajaba desarrolla tecnología, el 90% de los involucrados no sabía de que diablos hablaba (shame on you Infotec); tuve que explicar la idea a analistas, subdirectores, directores, consultores y desarrolladores sin demasiado éxito (nadie es profeta en su propia tierra, aunque me gusta pensar que di luz a algún alma perdida).

    Tengo que agregar que la palabra gamification se escucha rara en inglés y las traducciones al español suenan aun peor, imagine decir en la reuniones todo el tiempo ludificación, juguetización o jueguización, estas palabras no ayudan mucho a la venta del concepto, como fruto de la experiencia llegué a la conclusión de que para adoptar la idea más fácilmente, hay que usar palabras como Productividad, Cambios de Comportamiento, Motivación y Preferencia (o engagement si prefiere el termino de marketing).

    Puntos, Medallas, Trofeos, Tablas de Posición

    Como responsable de un proyecto hace tiempo, requería hacer un aseguramiento de calidad en una serie de contenidos para cursos, con mucha información por revisar y muy poco tiempo, le dije a los miembros de mi equipo, que las 2 personas que encontraran más errores se ganaban un café grande diario durante toda la semana siguiente. Repentinamente tenía un juego en marcha.

    Afortunadamente, no siempre necesitamos recurrir a premios físicos reales en todos los casos. El manejo de información que los usuarios le proporcionan a su organización, sitio web o aplicación móvil puede ser utilizado para otorgar premios en diferente forma, las más comunes son:

    • Puntos
    • Medallas
    • Trofeos
    • Niveles
    • Tablas de Posición
    • Retos
    • Logros

    En un sitio o sistema web, por ejemplo, el concepto es utilizado ampliamente para que sus usuarios hagan más dentro del sitio o estén más tiempo expuestos a determinada información. Algún sitio donde se hacen trámites, puede hacer del llenado de sus formularios algo más ameno dando alguna especie de puntaje o jerarquía relacionada con un progreso por cada paso completado. Un sitio de ventas puede dar trofeos o medallas por las reseñas que un usuario coloca acerca de algún producto.

    Estos ejemplos son ciertamente algo muy simple ya que solo buscan motivar más a los usuarios a llevar a cabo una tarea, y desde luego que dejan mucho más para explotar el concepto, pero son un buen punto de inicio para explorar los beneficios de gamification.

    No todo es dinero

    Un argumento extraño y limitado que me topé al proponer gamification, es que bajo la suposición de alguien, gamification se trataba de dar incentivos económicos en forma de efectivo, cupones o descuentos, lo cual no necesariamente es cierto, y caer en ese supuesto usualmente crea preocupación y hasta rechazo por parte de los patrocinadores de cualquier proyecto o cadena de producción (¿qué pasa con tus directores Infotec? :D). El dinero es un buen motivador para un usuario (siempre lo es), pero hay una palabra en inglés que encontrará mucho en los blogs y libros sobre gamification y que ya mencioné, esta es engagement, esto quiere decir que el dinero siempre lo motivará a hacer alguna tarea pero no necesariamente hará que se “enganche” o que disfrute con la misma.

    ¿Qué más?

    Si usted comienza a profundizar más en los temas de gamification, eventualmente se dará cuenta que hay mucho más que solo depender de incentivos y ciertamente mucho más que depender del dinero. Usted estará utilizando el comportamiento humano y el famoso cerebro reptiliano, es decir, usará a su favor algo que está dentro de la naturaleza humana, jugar. Usando gamification usted estará apelando a sentimientos de orgullo y necesidad de reconocimiento, con lo cual podría lograr incluso más que ofreciendo dinero.

    Para concluir

    Le dejo videos de algunos proyectos educativos donde apliqué gamification (algo viejos pero vigentes para entender el concepto) y algunas bibliografías que encontré útiles e interesantes:

    Libros:

    1. Why we do what we do: understanding self-motivation
    2. For the Win: How Game Thinking Can Revolutionize Your Business
    3. A Theory of Fun for Game Design

    Videos:

     Interactivo Prevención de Riesgos

    Interactivo Desarrollo Económico de México

    Juego de cartas para ayudar a aprender inglés HTML5

    Enlaces relacionados:

    Gamification Y LinkedIn

    U.S. Army – America’s Army (Cómo el ejército de E.U.A. ahora utiliza gamification para atraer nuevos reclutas)

    Mint (Empresa con aplicaciones fintech que utiliza gamification para las finanzas personales)

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    3 Comments
  • HTML unknow

    ¡HTML5, HTML Living, HTML Next y el drama!…¿HTML6?

    HTML_unknow
    Durante las charlas que he tenido oportunidad de dar ante una audiencia o bien por alguna red social me he topado con algunos planteamientos que hacen referencias a HTML6 (OMG!!!!) o bien a HTML Living y/o HTML Next, a que HTML5 ya caducó (OMG again!!!) y otra serie de afirmaciones o preguntas que van de lo veraz a lo absurdo, pasando por verdades a medias. Para aclarar un poco la situación he decidido hacer esta entrada y describir lo que pasa:

    Algo de contexto.

    HTML5 ha sido una exitosa tecnología apoyada por muchas organizaciones con diferentes perfiles e intereses relacionados de diferente forma con el desarrollo web, como son empresas, universidades, organizaciones civiles,etc., pero el grupo más representativo y con mayor historia aunque no siempre el más influyente, ha sido el World Wide Web Consortium (W3C) el cual ha generado muchas recomendaciones para la world wide web, estas recomendaciones van dirigidas mayormente al desarrollo del HTML y tecnologías conexas. Sin embargo la W3C no ha sido el único grupo haciendo recomendaciones y trabajando constantemente para evolucionar el HTML y tecnologías relacionadas desde su perspectiva, otro de estos grupos el cual sin duda obtuvo gran relevancia es el Web Hypertext Application Technology Working Group (WAHTWG). Ambos grupos han sido importantes gracias a sus iniciativas y a sus miembros, los cuales incluyen entre otros a organizaciones tan influyentes como Google, Microsoft, Apple, Adobe, Mozilla Fundation y Opera Software.

    En el 2007 ambos grupos deciden unir fuerza y utilizar la especificación HTML propuesta por WAHTWG como punto de partida para continuar con el desarrollo de la especificación HTML, lo cual se conoció eventualmente como HTML5. Dado esto, todas las nuevas especificaciones se comenzaron a publicar de manera oficial por me dio de W3C, sin embargo el principal y único editor oficial con la facultad de publicación fue el miembro de WAHTWG, Ian Hickson.

    El ascenso de HTML5.

    Gracias al esfuerzo conjunto de ambas organizaciones y sus miembros HTML5 comenzó a hacerse popular, adquiriendo muchísima más relevancia extra gracias el exponencial crecimiento de dispositivos móviles y las ventajas técnicas que representa HTML5 sobre las alternativas dominantes hasta el momento. El punto quizá más relevante para la popularidad de HTML5 surgió gracias a las polémicas declaraciones del entonces CEO de Apple Steve Jobs, quien puso de manifiesto las desventajas de desarrollar para los nuevos dispositivos utilizando el entonces estándar de facto en la realización de implementaciones de rico contenido gráfico, Flash.

    Desde luego un factor esencial para el éxito de HTML5 es que W3C  incluye entre sus miembros  a aquellos que también son los fabricantes de los principales navegadores, y que estos tratando de apoyar la nueva especificación dieron soporte a HTML5 haciendo que Chrome, Explorer, Safari, Mozilla y Opera lo soportaran aunque con diferentes grados de avance en su implementación. Todas estas circunstancias favorecieron a que HTML5 pudiera tener nombre, presencia, crecimiento e incluso logotipo que lo identifica ante propios y extraños.

    El drama.

    Desafortunadamente no todo es felicidad, como sucede en todas las organizaciones (creo) existe desacuerdos  y complicaciones. Desde el 2011 se escapaba uno que otro rumor que giraba en torno a diferencias entre W3C y WAHTWG, sin embargo el punto de quiebre es cuando efectivamente estas organizaciones deciden separarse a mediados del 2012 e Ian Hickson publica una carta abierta donde explica el status de la relación entre ambos grupos. Pero ¿que pasó en realidad? bueno pues todo son versiones de diferentes fuentes y no puedo corroborarlo todo, pero si me permite resumiré todo lo que he leído en 3 puntos persistentes en la mayor parte de las fuentes consultadas:

    • W3C está más preocupado por la estandarización de HTML mientras que WAHTWG está más preocupado por la implementación de HTML. Esto significa que la W3C está priorizando más el orden y la consistencia de la especificación para que los fabricantes de navegadores y relacionados cuenten con una referencia más precisa y mucho más compatible, mientras que WAHTWG considera que lo más importante es dar más y mejores características innovadoras a HTML para ampliar la gama de posibilidades en la creación de todo tipo implementaciones.
    • Descontento del editor. Ian Hickson es una persona que sin duda se ha hecho de un nombre en la industria y comunidad web ya que ha trabajado para diferentes empresas de mucho peso y ha colaborado con el desarrollo de varias especificaciones importantes, actualmente como empleado de Google y anteriormente como único editor oficial de la especificación HTML5, parte de su trabajo consistía en analizar, corregir y conciliar las diferencias de las propuestas técnicas de la W3C y WAHTWG con respecto a la especificación, lo cual lo llevó eventualmente manifestar su inconformidad con las implicaciones y diferencias entre las propuestas y en tener que unificarlas. Otro factor de desacuerdo es la visión de Hickson acerca de irrelevancia de usar versiones en la especificación HTML, ya que desde su punto de vista no debería existir HTML4, HTML5, HTML6, etc., sino simplemente HTML con su intrínsica evolución.
    • Intereses y DRM. Hasta el día de hoy existe muchas críticas hacia la W3C, ya que varios grupos argumentan que la insistencia de este grupo por estandarizar HTML obedece principalmente al interés de las empresas más grandes que son miembros de la organización ya que buscan maneras de patentar y hacer desarrollos cerrados, lo que incluye la posibilidad de integrar DRM a la especificación. Algunas de las voces que suman ha estas críticas son la Free Software Foundation, Web Content Accessibility Guidelines Working Group (WCAGWG), la propia WAHTWG y su miembro Ian Hickson.

    Las consecuencias…HTML Living y HTML Next

    La especificación HTML5 ha tenido diferentes “deadlines”…2011, 2012, 2014, 2022, todos estos años han sido mencionados para terminar la especificación, pero la verdad sea dicha, nadie sabe a ciencia cierta cual será la fecha final o la versión buena, ni siquiera todas las agrupaciones mencionadas, ya que todo obedece a muchos factores incluyendo desacuerdos y reconciliaciones (sí, cual telenovela de quinceañer@s despechad@s).

    La última afirmación extraoficial es que W3C se ha fijado el 2014 para terminar la especificación HTML5 y desde ahí comenzará la especificación de lo que llama HTML Next o HTML5 Next. Por su parte,  WAHTWG ha comenzado con lo que llama la especificación HTML Living.

    ¿HTML6?

    Permítame aclaro esto de una vez por todas, hoy NO EXISTE ALGO QUE SE LLAME HTML6, lo que a algunas personas les ha dado por llamar HTML6 es precisamente al conjunto de los conceptos HTML Living y HTML Next, los cuales ningún navegador soportará todavía, HTML6 NO es un nombre oficial ni nada por el estilo, mañana tal vez, pero hoy por hoy no lo es.

    ¿Cómo nos afecta esto a los desarrolladores?

    !No lo sabemos!, antes de que cunda el pánico y corra a buscar libros y manuales de HTML Living y HTML Next, la realidad es que la última palabra la tendrán los fabricantes de navegadores que son los que decidirán a que especificación apoyar en su momento, pero tenga presente que las cosas en el mundo de la tecnología cambian muy rápido y a veces de manera inesperada, y que las empresas y las organizaciones son finalmente dirigidas por personas que pueden cambiar de opinión en cualquier momento, ¿alguien se acuerda del choque Blu-Ray VS HD-DVD, donde supuestamente ganó el BR? (aunque el verdadero ganador fue el streaming). Por otro lado, si quiere saber el peor de los casos, este sería que los desarrolladores tuviéramos que lidiar con dos especificaciones HTML.

    ¿Debería dejar de aprender HTML5?

    NOOO!! no cometa ese error, HTML5 sigue vigente y avanzando y aun si HTML Living y HTML Next ven la verdadera luz, ambas especificaciones partirían desde lo que hoy es HTML5, de manera que es todo lo contrario, hay que continuar aprendiendo HTML5.

    Todo por ahora, cualquier comentario, pregunta, aclaración o queja con gusto en los comentarios de este post o en @ManuGekko

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    No Comment
  • Arrastrar y Soltar

    Arrastrar y Soltar HTML5

    Arrastrar y Soltar

    Arrastrar y Soltar en HTML5

    Sin duda la posibilidad que introdujo HTML5 para Arrastrar y Soltar de manera nativa representó un avance, esto sin duda fue una novedad ya que en la era pre-HTML5, la única manera de lograr esto era con la utilización de complejas operaciones con JavaScript, por lo que la mayoría de los desarrolladores terminábamos utilizando alguna librería como JQuery, MooTools u otras para contar con la funcionalidad de Arrastrar y Soltar (Drag and Drop), o si la situación requería de mucha interactividad y gráficos la utilización de Flash era casi imperiosa. La clase nativa para Arrastrar y Soltar de HTML5 lleva un tiempo existiendo pero tenía varios problemas que se han ido solucionando poco a poco. El principal problema quizá era que los ejemplos que se podía encontrar por ahí, continuamente solo funcionaban en un navegador y no en los demás, pero los fabricantes han ido homologando cada vez más la clase aunque no todos todavía. La clase aún no es totalmente perfecta y tiene aún varios detractores y críticos muy enfáticos, sin embargo, posee varias ventajas sobre otras opciones. En esta entrada abordaré lo que necesita saber para comenzar a utilizar la clases Arrastrar y Soltar de HTML5 explicando sus puntos más básicos e importantes. Puede ver el ejemplo que a continuación explicaré en este enlace, comencemos…

    Ventajas sobre otras implementaciones Arrastrar y Soltar

    Como mencioné, he podido encontrar que en varios blogs aseguran que el Arrastrar y Soltar de HTML5 no debería ser utilizado, a lo cual me gustaría contra argumentar, sobre todo porque la clase me ha sido de gran ayuda últimamente:

    • Interacción con otras aplicaciones o aplicacion de derivadas. La implementación del Arrastrar y Soltar de HTML5 permite la interacción entre iframes e incluso entre ventanas de navegadores. Si me permiten ser un poco entusiasta en este punto, invito a quien sea a que intente implementar un Arrastrar y Soltar entre iframes y/o ventanas utilizando librerías JavaScript…¡el horror!….
    • El framework nativo es independiente de terceros. Tener una clase nativa siempre tiene la ventaja de independencia en cuanto a las situaciones que pueden rodear y afectar al desarrollo de un tercero, lo que evidentemente no sucede con las alternativas que presentan JQuery, MooTools, Dojo, etc., ahí la dependencia es total.
    • Interacción con aplicaciones que no son web. Un ejemplo de esto es que ahora es posible arrastrar un archivo del escritorio a una aplicación en el navegador.

    Las bases, paso a paso

    Para facilitar un poco las cosas he organizado esta entrada en pasos, cada paso describe un concepto o varios que iré ejemplificando.

    1. Especificando los elementos arrastrables (draggable object)

    Lo primero que necesita hacer es definir que nodo o nodos del documento HTML5 serán susceptibles de ser arrastrados, en HTML5 casi cualquier elemento visible puede ser arrastrado, como son imágenes, divs, links, etc., para lograr esto se utiliza el atributo draggable=”true”. Por ahora no aplica el manejo de valores falso o verdadero a  la manera clásica de XHTML en los navegadores que he probado, es decir, al atributo no funciona si lo escribimos como draggable=”draggable” incluso dentro de un archivo xhtml. También hay elementos que son arrastrables por default para algunos navegadores, como lo son imágenes y selecciones de texto. En el sigiente ejemplo se muestran algunos cuadros que serán los elementos arrastrables para este ejemplo:

    <div id="squares">
        <div class="square" draggable="true">
            <h1>1</h1>
        </div>
        <div class="square" draggable="true">
            <h1>2</h1>
        </div>
        <div class="square" draggable="true">
            <h1>3</h1>
        </div>
    </div>

    Acompañando este código colocamos los siguientes estilos CSS:

    .square {
    height: 100px;
    width: 100px;
    border: 1px solid #000;
    float: left;
    background-color: #eee;
    margin: 5px;
    -webkit-box-shadow: inset -1px -1px 3px #000;
    -ms-box-shadow: inset -1px -1px 3px #000;
    box-shadow: inset -1px -1px 3px #000;
    text-align: center;
    cursor: move;
    }
    
    h1 {
    font-size: 75px;
    }
    
    .target {
    height: auto;
    min-height: 150px;
    width: 320px;
    float: left;
    border: 1px solid #000;
    margin: 5px;
    background-color: #ccc;
    -webkit-box-shadow: inset -1px -1px 3px #000;
    -ms-box-shadow: inset -1px -1px 3px #000;
    box-shadow: inset -1px -1px 3px #000;
    text-align: center;
    cursor: move;
    }

    En navegadores webkit (Chrome, Safari) y Firefox el código anterior nos presenta una serie de cuadrados que originarán una especie de “fantasma” si intenta arrastrarlos, ahora hay que agregar los eventos apropiados. Resultado:

    2. Asignando eventos a los elementos arrastrables (Drag Objects)

    Ahora que tenemos los objetos que deseamos se puedan arrastrar, debemos asignarles algunos eventos utilizando JavaScript, estos objetos pueden disparar lo siguientes tres eventos:

    • dragstart. Se dispara cuando el usuario comienza a arrastrar el objeto.
    • drag. Se dispara cada vez que el puntero del mouse se mueve mientras que un objeto está siendo arrastrado.
    • dragend. Se dispara cuando el usuario suelta el botón mientras un objetos está siendo arrastrado. Estos eventos se asignan como lo hace normalmente JavaScript o la librería de su preferencia. Vamos a agregar unos cuantos elementos al código HTML:
    <div id="squares">
        <div class="square" draggable="true">
            <h1>1</h1>
        </div>
        <div class="square" draggable="true">
            <h1>2</h1>
        </div>
        <div class="square" draggable="true">
           <h1>3</h1>
        </div>
    </div>
    <p id="event"></p>
    <p id="status_drag"></p>
    <p id="status_over"></p>
    <p id="status_drop"></p>

    Agreguemos el siguiente código JavaScript para asignar los eventos descritos a nuestros cuadros:

    /*
    * En el evento dragstart se coloca un mensaje que se verá muy brevemente
    * o quizá no se note, cuando el usuario inicia el arrastre
    */
    function dragStartEvent(e) {
        eventStatus.innerHTML = "evento  dragStart"
    }
    
    /*
    * El evento drag reporta al usario cuando inicia y que un arrastre
    * está actualmente en progreso
    */
    function dragEvent(e) {
        eventStatus.innerHTML = "evento drag."
        dragStatus.innerHTML = "Arrastrando en este momento.";
    }
    
    /*
    * El evento dragover despliega un mensaje cuando es llamado y otro que
    * que indica que el arrastre ha terminado
    */
    function dragEndEvent(e) {
       eventStatus.innerHTML = "evento dragend."
       dragStatus.innerHTML = "Arrastre terminado."
    }
    
    //variables para elementos informativos
    var eventStatus = document.getElementById('event');
    var dragStatus = document.getElementById('status_drag');
    //variable para alamacenar todos los divs que usan la clase square
    var squareItems = document.querySelectorAll('.square');
    
    //ciclo para asignar los eventos a cada cuadro (div square)
    [].forEach.call(squareItems , function(squareItem) {
        squareItem.addEventListener('dragstart',dragStartEvent, false);
        squareItem.addEventListener('drag',dragEvent, false);
        squareItem.addEventListener('dragend',dragEndEvent, false);
    });

    Este código deber ser llamado cuando el documento HTML está cargado, note como simplemente se asignaron los eventos y estos despliegan mensajes cuando son disparados.

    3. Asignando eventos al elemento objetivo (Drop Object)

    Hasta ahora hemos logrado arrastrar elementos por la ventana, pero tenemos que asignar algún objeto en donde los elementos arrastrables puedan ser soltados, a este elemento lo llamaremos objetivo o drop target. Al elemento objetivo o drop target le podemos asignar los siguientes eventos:

    • dragenter. Se dispara cuando un objeto arrastrable es el primero en arrastrase dentro de un objeto.
    • dragover. Se dispara cuando un objeto arrastrable es arrastrado dentro de un objeto. Hay que tener presente que si se desea que el objeto que está siendo arrastrado pueda ser soltado dentro de otro, debe cancelar el comportamiento por default de este.
    • dragleave. Se dispara cuando un objeto arrastrable es arrastrado fuera de un nodo objetivo.
    • drop. Se dispara cuando un objeto arrastrable es soltado dentro de un nodo objetivo. Si desea convertir un objeto en un elemento o nodo objetivo que permita soltar elementos arrastrables, debe de asignar los eventos dragover y drop de manera obligatoria, es fácil entender porque el evento drop debe ser usado, pero quizá no sea tan claro porque dragover también, la razón es porque el elemento que se está arrastrando puede tener otro funcionamiento que no se desea cuando se suelta, por ejemplo, si está arrastrando un enlace y no previene el comportamiento por default, cuando suelte este elemento el navegador se direccionará a la URL del enlace como si usted hubiera hecho un clic normal, lo que no es deseable mientras se arrastra y se suelta el elemento. Al código que tiene actualmente, agregue al final el elemento objetivos para soltar el elemento:
    <div id="target1" class="target">Suelte elementos aquí</div>

    Agregaremos dos variables solo para alertar cuando se disparan los nuevos eventos y tener mejor idea de que el elemento objetivo está siendo efectivamente afectado.

    var overStatus = document.getElementById('status_over');
    var dropStatus = document.getElementById('status_drop');

    Y claro el código para asignar los nuevos elementos:

    dropItem.addEventListener('dragover', dragOverEvent, false);
    dropItem.addEventListener('drop', dropEvent, false);

    Los otros ventos que no incluí no son indispensables (dragenter y dragleave) pero son útiles, por ejemplo, para ofrecer más indicadores visuales al usuario y hacer una experiecia más intuitiva, pero por ahora lo omito para mayor claridad, si desea más ejemplos incluyendo estos eventos, recuerde que en el pedir está el dar 😉 Resultado:

    4. Transferecia de datos del elemento arrastrable al elemento objetivo (Datratrasfer object).

    En este punto está casi todo listo, pero donde culmina todo lo que hemos hecho es en la transferencia de datos del elemento que estamos arrastrando. Por ahora, aunque nuestro elemento parace estar haciendo todo bien, aún no lo logra ser “soltado” dentro del elemento objetivo como esperaríamos, es aquí donde la transferencia de datos hace su magia. Lo que se necesita es la propiedad dataTransfer y sus métodos setData() y getData(). Lo primero es utilizar el método setData() dentro de uno de los eventos asignados al elemento que se arrastra, usualmente se utiliza el evento dragstart, por parte de los eventos del elemento objetivo, estos pueden recibir los datos transferidos en algunos de sus eventos asignados, es ahí de donde se utiliza getData(), entonces: setData(format, data). Establece la información que se intercambia entre el nodo que se arrastra y y el nodo objetivo. El parámetro format establece el tipo de dato que se va a intercambiar, hasta ahorita los únicos tipos de dato que existan son “text” y “url” (se usa el formato de mimetype). El parámetro data es el información persé que sera intercambiada, lo cual es una cadena de texto, comunmente se utiliza innerHTML. getData(format). Recupera la información que fue previamente asignada por setData(), el setData puede estar incluso en otra página, incluso en otro navegador. El parámetro format es el tipo de dato asociado con lo que se espera, los tipos de dato pueden ser “text” y “url” (se usa el formato de mimetype). Ahora utilicemos lo que hemos aprendido en nuestro código. Dentro del evento dragstart coloquemos la siguiente línea:

    e.dataTransfer.setData('text/html', this.innerHTML);

    Con la línea anterior ha preparado la información que se va a transferir en el arrastre, ahora toca el turno de indicarle al nodo objetivo cual es información que va a recibir cuando el usuario suelte el elemento que está arrastrando, sin más agreguemos las siguientes líneas de código al evento drop:

    var dropedelement = document.createElement('span');
    dropedelement.innerHTML = e.dataTransfer.getData('text/html');
    this.appendChild(dropedelement);

    Para terminar.

    El código JavaScript completo debería lucir aproximadamente de la siguiente manera:

    /*
    * En el evento dragstart se coloca un mensaje que se verá muy brevemente
    * o quizá no se note, cuando el usuario inicia el arrastre
    */
    function dragStartEvent(e) {
        eventStatus.innerHTML = "evento  dragStart.";
        overStatus.innerHTML = "";
        dropStatus.innerHTML = "";
        e.dataTransfer.setData('text/html', this.innerHTML);
    }
    
    /*
    * El evento drag reporta al usario cuando inicia y que un arrastre
    * está actualmente en progreso
    */
    function dragEvent(e) {
        eventStatus.innerHTML = "evento drag.";
        dragStatus.innerHTML = "Arrastrando en este momento.";
    }
    
    /*
    * El evento dragover despliega un mensaje cuando es llamado y otro que
    * que indica que el arrastre ha terminado
    */
    function dragEndEvent(e) {
        eventStatus.innerHTML = "evento dragend.";
        dragStatus.innerHTML = "Arrastre terminado.";
    }
    
    /*
    * El evento dragend despliega un mensaje cuando es llamado y otro que
    * que indica sobre que elemento objetivo se arratra actualemte, si es
    * el caso
    */
    function dragOverEvent(e) {
        if (e.preventDefault) {
            e.preventDefault(); // Necesario para permitir soltar.
        }
        eventStatus.innerHTML = "evento over.";
        overStatus.innerHTML = "Elemento arrastrable sobre " + this.id;
    }
    
    /*
    * El evento drop despliega un mensaje cuando es llamado y otro que
    * que indica en que elemento objetivo se ha soltado el elemento
    */
    function dropEvent(e) {
        eventStatus.innerHTML = "evento drop";
        dropStatus.innerHTML = "Se ha soltado un elemento dentro de " + this.id;
        var dropedelement = document.createElement('span');
        dropedelement.innerHTML = e.dataTransfer.getData('text/html');
        this.appendChild(dropedelement);
    }
    
    //variables para elementos informativos
    var eventStatus = document.getElementById('event');
    var dragStatus = document.getElementById('status_drag');
    //variables para elementos informativos
    var overStatus = document.getElementById('status_over');
    var dropStatus = document.getElementById('status_drop')
    //variable para alamacenar todos los divs que usan la clase square
    var squareItems = document.querySelectorAll('.square');
    var dropItem = document.getElementById('target1');
    
    //ciclo para asignar los eventos a cada cuador (div square)
    [].forEach.call(squareItems , function(squareItem) {
        squareItem.addEventListener('dragstart',dragStartEvent, false);
        squareItem.addEventListener('drag',dragEvent, false);
        squareItem.addEventListener('dragend',dragEndEvent, false);
    });
    
    dropItem.addEventListener('dragover', dragOverEvent, false);
    dropItem.addEventListener('drop', dropEvent, false);

    Lo que obtenemos tiene este aspecto después de arrastrar todos los elementos:

    Note que este ejemplo copia los elementos en lugar de moverlos (no elimina el elemento original) pero usted puede hacerlo si lo desea. Por supuesto se pueden hacer implementaciones un tanto más sofisticadas, pero por ahora usted ha cubierto las bases para posteriormente hacer un uso más interesante e intenso de la la clase Arrastrar y Soltar de HTML5.  Si usted tiene alguna opinión, crítica, aportación o cualquier otra cosa, deje un comentario en esta entrada, o bien envíelo a @ManuGekko o @RealInernet80 en Twitter.

    Otros enlaces de interés:

    Arrancar con HTML5 Curso de Programación

    Subir un archivo con HTML5

    Transiciones y Transformaciones en Botones (CSS3 y HTML5)

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    No Comment
  • Flash-VS-HTML-5

    Flash VS HTML5 (Parte 4)

    Que se pongan de pie todas las personas que alguna vez han querido ver algún video, y repentinamente hayan comentado algo como “oye, se escucha, pero no se ve”, y después de un rato de experimentar, preguntar e indagar llegan a la conclusión de que “falta el bendito codec”.

    Situaciones como estas existen prácticamente desde que la computadoras permiten ver video, pero en estos días este tema aflora con nueva fuerza,  debido al contexto del video en la Web dentro de la nueva especificación HTML5, que incluye el nuevo elemento <video>, el cual permite añadir este tipo de contenido fácilmente sin requerir plug-ins de terceros, como lo es el Flash Player entre otros.

    Diferencia entre FORMATO DE ARCHIVO DE VIDEO y CODEC.

    Primero aclararé un punto de confusión tremendamente común, siempre que puedo lo hago porque, de verdad, existe una graaaaan confusión al respecto entre los consumidores de video.

    Los formatos de archivo de video como .mov, .avi, .rm, .flv, etc., solo son el formato contenedor de la información de un video, pero este formato ¡NO es el codec ni de imagen, ni de audio para ver el video!. Para aclarar esto me auxilio constantemente del archivo de compresión .zip, si usted desea guardar cualquier tipo de archivo en en un formato de compresión como ZIP,  simplemente incluye este contenido dentro de un archivo con extensión .zip y no se preocupa si tal contenido son imágenes, archivos .doc, archivos .pdf o cualquier otra cosa. Cuando otra persona descomprime ese archivo .zip  puede obtener los archivos guardados dentro, y dependerá de si esta otra persona cuenta con Word para ver los archivos .doc, o Adobe Reader para ver archivos .pdf, de no contar con las herramientas necesarias para ver los archivos enviados dentro del archivo .zip no será posible verlos aunque cuente con los archivos completos y correctos.

    Hablando de video, el equivalente al archivo .zip son los archivos en formato avi, mov, flv, etc., estos son solo el formato del archivo contenedor, dentro se almacena información codifica para los cuadros que forman un video, y la información codificada que corresponde al audio, para decodificar esta información requerimos del codec apropiado. Si no contamos con los codecs indicados para el video y el audio, no será posible ver el video en cuestión correctamente aunque el video persé no tenga ningún problema, así como sucedería si no contamos con Word para ver el archivo .doc en el ejemplo del archivo .zip.

    La parte más inconveniente en lo que respecta al video en HTML5 es que estamos en medio de una nueva “guerra de navegadores” y los fabricantes no se han puesto de acuerdo acerca de cual deber ser el formato estándar para desplegar video y por lo tanto tampoco de cuales codecs deberían ser usados. Por lo que debemos estar pendientes de que navegador es compatible con que codecs de video (la wikipedia cuenta con una sección que se ha actualizado recurrentemente)

    ¿Cómo funciona?

    No describiré demasiado como insertar un video flash en una página, ya que dada la longeva presencia de flash existe una gran cantidad de recursos donde se enseña como hacer esto con gran detalle. La novedad por el momento recae más en la etiqueta <video> que busca trabajar casi con la misma facilidad con que lo hace la etiqueta <img>, el elemento video cuentan con varios atributos como src, control, autoplay, width, height, poster y otros más:

    <video src="video.mp4" width="360" height="240" controls="controls">
    </video>

    ¿Qué formato utilizar?

    No se cuenta aun con un formato universal e infalible para todos los navegadores, pero podemos utilizar múltiples formatos en la misma etiqueta video, en caso de que el navegador no reconozca un formato se irá al siguiente:

    <video controls width="350" height="250">
     <source src="video.ogv" type="video/ogg" />
     <source src="video.mp4" type="video/mp4" />
    </video>

    ¿Qué hacer si el navegador no soporta ningún formato?

    Si el navegador no soporta ninguno de los formatos que se han colocado siempre se puede colocar el video en formarto Flash y verlos de esa manera:

    <video controls width="350" height="250" >
        <source src="video.ogv" type="video/ogg" />
        <source src="video.mp4" type="video/mp4" />    
        

    http://player.swf?file=video.mp4

    
    </video>

    Al momento algunos navegadores responden mejor que otros al elemento video, y muchas personas utilizan navegadores viejos, para estos casos Flash es todavía una buena alternativa, aunque la tendencia parece indicar que el elemento video se consolidará cada vez más poco a poco.

    La comparación

    Cuando se trata de video, HTML5 en general tiene mejor rendimiento en términos de consumo de recursos y más fácil de implementar cuando hablamos de código, pero por el momento la distribución de Flash es mayor y funciona igual en todos los navegadores una vez que estos tienen el plug-in instalado. Flash tiene manejo de pantalla a tamaño completo, HTML5 no por el momento, aunque se sabe que se trabaja sobre ello. Flash soporta video en streaming, HTML5 lo hará en el futuro pero por ahora no lo puede hacer.

    Todas las desventajas del video en HTML5 sobre Flash parecen ser temporales y a esto se suma que Adobe anunció recientemente (Nov 2011), que ya no habrá desarrollo de Flash para móviles, veremos que pasa!

    Ir a parte 3       Ir a parte 5

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    No Comment
  • Flash-VS-HTML-5

    Flash VS HTML5 (Parte 3)

    Por alguna razón mucha gente buscamos que haya buenos y malos en muchas situaciones, casi sin cuestionamiento el títlo de bueno se le ha dado a HTML5, los malos Flash y Silverligth y si desea agregar el feo quizá una vez más Silverlight.

    La realidad es que no hay bandos reales, lo que tenemos son más opciones y eso es lo que hay que aprovechar. Por supuesto habrá situaciones donde hay que elegir, y para tomar decisiones hay que conocer algunas características de nuestras alternativas:

    Animación.

    Flash.

    Primero hay que estar al tanto que Flash nació como una herramienta de animación en un sentido más tradicional, la primera herramienta que creaba contenido Flash era un programa con herramientas del tipo “diseño gráfico” como líneas, círculos, rectángulos, bote de pintura, etc., y con una línea de tiempo para colocar las figuras dibujadas frame a frame y manipularlas de acuerdo a lo que se deseaba.

    Flash ha evolucionado y ya no cuenta con una sola herramienta para crear contenido, Flash ya no solo está orientado a sólo a hacer animaciones “artísticas o experimentales” si no que inclinado a ser un verdadero framework para crear aplicaciones conocidas como RIAs (Rich Internet Aplications), en estas puede combinar diferentes grados de animación.

    Ventajas:

    • Hacer y animar fluidamente dibujos de trazo libre es amable y fácil.
    • Hay una amplia comunidad desarrollo.
    • Existe mucha documentación libre y de pago.
    • Adobe está constantemente mejorando esta tecnología.
    • Los resultados visuales que se pueden obtener son realmente de muy alta calidad.

    Desventajas:

    • Se require de un plug-in de tercero instalado para ver contenido Flash.
    • La versión del plug-in puede ser un factor problemático para usuarios y desarrolladores.
    • El contenido Flash no es indexable, esto dificulta que los buscadores y otras herramientas  ubiquen, interpreten y clasifiquen su contenido.
    • Además  de conocer HTML, JavaScript, CSS, etc., hay que aprender ActionScript y múltiples herramientas para explotar verdaderamente el potencial de Flash.
    • Los elementos más interesantes de la plataforma Flash son propietarios, por lo tanto tienen costo.

    HTML5

    La animación en HTML5 cuenta con varias alternativas para ser creada, puede usar solo JavaScript y CSS3, puede utilizar el elemento Canvas o la tecnología SVG. Todos estas alternativas han sido creadas desde un punto de vista programático, es decir, siempre se pensó en crear animaciones utilizando código de programación y no una  herramienta de diseño con una interfaz de usuario.

    HTML5 se encuentra evolucionando rápidamente y mucha gente está prestando atención, la misma compañía dueña de Flash ha estado experimentando con las posibilidades de este nuevo estándar y proponiendo cosas, como la importación de contenido desde la aplicación Adobe Flash a HTML5, la creación de Adobe Edge (que si me preguntan es un intento de hacer de HTML5 lo que Flash fue originalmente) , entre otras cosas.

    Ventajas:

    • Todo es libre y gratuito.
    • No existe necesidad de utilizar plug-ins.
    • Una rápidamente creciente comunidad de desarrollo y documentación.
    • La indexación de contenido combinado con la fuerte semántica de HTML5 van de la mano de gran manera.

    Desventajas:

    • HTML5 no es lo más conveniente para la animación detallada y fluida (del tipo dibujo animado) por ahora.
    • HTML5 no es una especificación terminada, por lo que hay cosas que aún no están concluidas o son experimentales.
    • No todos los navegadores soportan todas las características de HTML5 o no las soportan de igual manera.
    • HTML5 no tiene aún buenas alternativas que sean amables con diseñadores gráficos.

    Cuando hablamos de animación, el consumo de recursos es un punto donde se critica mucho a Flash, pero tengo que admitir que Adobe se está esforzando mucho en este sentido y HTML5 aunque promete en este tema, tiene sus bemoles en ciertas circunstancias, habrá que esperar un poco para definir este punto con claridad.

    Conclusiones:

    Si desea hacer animaciones con trazos libres, que no requieren demasiada programación pero si mucho trabajo gráfico y deben ser de gran fluidez, mi recomendación es Flash.

    Si desea hacer aplicaciones de escritorio con moderado grado de animación y muy  buena presentación, considere utilizar AIR , si desea importar estas aplicaciones a la web o viceversa Flex es una buena opción (estas tecnologías son parte de la plataforma Flash).

    Si desea hacer aplicaciones web con moderado grado de animación y desea familiarizarse con los estándares del futuro vale la pena dedicarle tiempo a HTML5.

    Si el presupuesto es un problema, los estándares libres siempre son una interesante opción, es claro que HTML5 brilla en este caso.

    En la siguiente parte de esta serie de posts abordaré ventajas y desventaja de estas tecnologías desde el punto de vista de video.

    Ir a parte 2         Ir a parte 4

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    No Comment
  • Flash-VS-HTML-5

    Flash VS HTML5 (Parte 2)

    En la entrada anterior hablé de la tecnología Flash y un poco de su historia, con el fin de comprender mejor de que va Flash desde su inicio. Ahora le toca el turno al famoso y esperado HTML5. De unos dos años para acá se ha hecho mucho escándalo alrededor del flamante HTML5, y con razón, ya que presenta muchas nuevas y prometedoras características.

    He observado que muchas persona caen en una impresición similar a cuando se habla de Flash, es decir se habla de HTML5 como un todo, como una especie de entidad única que merodea en la Web creando páginas interesantes. La verdad es que HTML5 es algo que viene acompañado de varías tecnologías con las cuales se complementa para poder funcionar.

    HTML5 es únicamente la especificación más nueva, publicada por la W3C para HTML, el lenguaje base para crear páginas Web. La especificación define como deberían escribirse las etiquetas o tags que instancian un elemento HTML en nuestras páginas, que atributos y eventos poseen. Eso es todo, y lo más curios de todo es que ni siquiera es una especificación completa ni terminada, pero entonces ¿por qué tanto escándalo? :

    HTML5 es más rigorista.

    Anteriormente si se escribía una página HTML podía caer en errores de escritura, combinar mayúsculas y minúsculas en el código, no cerrar etiquetas que requerían cierre, ignorar tipos MIME, entre otras cosas de mal gusto para programadores exigentes, y las páginas en muchos casos aún se veían como se esperaba, haciéndonos olvidar todos los errores cometidos y creando malos hábitos. Para intentar solucionar esto se creó XHTML, pero nunca fue ciento por ciento adoptado por todos los desarrolladores. HTML5 intenta recuperar el espíritu de precisión de XHTML, mantener la familiaridad de HTML y unificarlo todo en la nueva especificación HTML5 (en el futuro crearé un post para hablar de XHTML2 y XHTML5 que tienen su historia, pero me lo guardo para no salir de contexto).

    El énfasis en la semántica en el código HTML es realmente notable e incluso abrumador cuando se comienza a desarrollar.

    Nuevas etiquetas para formularios.

    Tengo la impresión de que este punto no es muy mencionado pero a mi me parece importante porque puede ahorrar tiempo y costos. HTML5 incluye una nueva serie de etiquetas para colocar nuevos controles para formularios, por ejemplo, barras de progreso, campos de texto que filtran números y patrones, campos de texto que validan direcciones de correo y URLs, campos de texto que muestra color pickers y calendarios, entre otros más. Este tipo de controles requerían de programación y tiempo extra o incluso de comprar controles de terceros, pero HTML5 lo incluye de entrada.

    Nuevas etiquetas para contenido multimedia.

    Este aspecto en realidad al que la mayoría de la gente se refiere cuando habla de HTML5. La nueva especificación propone nuevas etiquetas para colocar audio y video de manera nativa sin el uso de plug-ins de terceros y/o propietarios, como justamente son el Flash Player o el reproductor de contenido Silverlight.

    Pone sobre la mesa el elemento Canvas, que es justamente uno de los recursos principales para crear animaciones con gráficos vectoriales e imágenes, sin embargo esto se hace hoy por hoy principalmente de manera programática, nótese esto porque será un punto importante para el encuentro mano a mano entre Flash y HTML5 para la tercera parte de la entrega de posts.

    CSS3 y JavaScript.

    Tecnologías sin las cuales HTML5 no podría hacer algo mínimamente  interesante  y que se encuetran evolucionando paralelamente al mismo HTML5. Esto es algo sumamente importante, ya que antes de alguien pueda pensar en que aprender HTML5 solo es conocer algunas etiquetas nuevas, la realidad es que si aspira a desarrollar con HTML5 debe aprender la nueva especificación para hojas de estilo nivel 3 o CSS3 y los nuevos recurso JavaScript. Combinando etiquetas HTML5, CSS3 y JavaScript se puede lograr una mucho mejor manipulación del aspecto y comportamiento de elementos HTML que nunca antes, logrando una mejor estética en nuestras páginas y en nuestro código al separar programación estructural de programación visual.

    Web sockets y Web workers.

    No hablaré mucho de esto, solo diré que aquellos gurús adentrados en programación con sockets y la programación por hilos tienen en HTML5 algo muy interesante por revisar.

    En la próxima entrada ¡comenzarán los verdaderos golpes!

    Ir a parte 1            Ir a parte 3

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    No Comment
  • Flash-VS-HTML-5

    Flash VS HTML5 (Parte 1)

    No se trata de una guerra, ni de una pelea, de hecho consideré titular esta entrada como Flash y HTML5 pero me pareció que el “versus” sería más provocador para los “fanboys“.  Personalmente creo que Flash se ha ganado el lugar que tiene en la Web, pero esto no quiere decir que siempre estará ahí, que siempre será la mejor o la única opción.

    Últimamente de manera continua algunas personas, que comienzan a desarrollar,  me han preguntado que es mejor y al mismo tiempo me he dado cuenta de algunas confusiones en el tema, de manera que decidí hacer una serie posts abordando el asunto y  esperando despejar algunas dudas a quienes desean desarrollar con estas tecnologías.

    Flash:

    Aveces se menciona a Flash como un todo, pero en realidad hay varias partes involucradas. Flash surgió como una tecnología  propuesta por la compañía Macromedia a finales de los 90s, que permitía desplegar gráficos vectoriales en páginas Web, Flash consta básicamente de un plug-in instalado en el navegador de un usuario que permite el despliegue de contenido elaborado en este formato, a esto se le conoce como Flash Player. Al mismo tiempo que Flash Player Macromedia creó la herramienta con la que originalmente se podía crear este tipo de contenido, esta herramienta fue concebida como un software de animación para crear contenido destinado principalmente a la Web, este software se le llamaba simplemente Flash.

    El Flash y el Flash Player han ido evolucionando lo largo de los años, durante este tiempo Macromedia liberó parte de su tecnología para permitir a terceros crear contenido SWF (el formato que comprende Flash Player), e esto se agregó la posibilidad de incluir video en formato FLV el cuál también se visualiza gracias a Flash Player. Otra parte importante de Flash es su script de desarrollo conocido como ActionScript el cuál también ha tenido cambios importantes.

    En 2005 la compañía Adobe (dueños de Photoshop) adquiere a Macromedia, con esto también vinieron cambios sobre Flash, la herramienta de autoría ahora se conoce como Adobe Flash Professional y surge también la nueva versión de su script el popular ActionScript3, el cuál introduce al desarrollo con Flash verdadera programación orientada a objetos.

    Una de las mayores limitantes de Flash ha sido su pobre interacción con datos y su poco practicidad para crear aplicaciones que buscaban más productividad y un tanto menos de animación como tal, manteniéndose aún sobre la Web pero considerando  también aplicaciones de escritorio. Adobe consciente de esto crea Flex y AIR, un conjunto de tecnologías que también crean contenido Flash pero con mejores capacidades en cuanto al desarrollo con el manejo de datos, y más orientada al desarrollo tradicional de aplicaciones.

    Las  grandes desventajas de las tecnologías basadas en Flash siempre han estado relacionadas con el rendimiento en general, el consumos de recursos y algunos temas de seguridad. Factores que hay que considerar antes de crear una aplicación.

    En la siguiente parte de esta entrada abordaré al novedoso HTML5…..

    Ir a parte 2

    IT professional with several years of experience in management and systems development with different goals within public and private sectors.

    1 Comment