Etiqueta: diseño

  • Flash VS HTML5

    Flash VS HTML5 Parte 5 (ahora sí la última parte….creo)

    Flash VS HTML5

    Historia

    Hace ya 3 años inicié una serie de entradas en este blog, en donde comparaba las tecnologías Flash y la entonces emergente HTML5, en aquel entonces atestigüé acalorados debates en diferentes foros y medios sobre las bondades y retos que estas dos tecnologías tenían enfrente, sin embargo hoy en día parece que tenemos claro para donde van las cosas, y aunque Flash se niega a morir y aun se puede encontrar a uno que otro nostálgico pero aguerrido defensor de esta tecnología (yo mismo fui entusiasta de Flash durante sus años de gloria), en este primer cuarto del 2015 se han colocado algunos de los clavos más firmes en el ataúd de Flash. Las malas noticias para Flash provenientes en esta ocasión de YouTube, Mozilla y de las mismas fallas de rendimiento y seguridad del plug-in Flash Player.

    Si es que alguien no lo sabe, Flash se propago ámpliamente hace más de década y media permitiendo a los desarrolladores web y multimedia crear gráficos, animación, video  y otras interacciones con el usuario que eran difíciles o imposibles para el navegador. Para que las creaciones en Flash pudieran ser visualizadas en los navegadores, tanto entones como ahora, se requiere de un plug-in llamado Flash Player, y es aquí donde comienzan los problemas para Flash (¿barbas a remojar para el plug-in de Java?).

    Con el poder de los navegadores incrementándose, la evolución de las capacidades de HTML5, la búsqueda del ahorro de recursos  y las nuevas propuestas que se suman en el camino, tenemos que los plug-in van de salida. El primer gran golpe para Flash fue el que dio el todavía vivo Steve Jobs desterrando a Flash del ecosistema del iPhone por ahí del 2010. Pero ahora tenemos tres nuevos golpes, aunque uno de ellos es engañoso y paradójicamente quizá le ofrezca un último asidero a Flash, veamos:

    Problemas de seguridad del Flash Player.

    Comenzando el año 2015 el Flash Player tuvo muchos problemas de seguridad, y la verdad sea dicha es el plug-in favorito de los black hat hackers lo que ha llevado incluso a sugerir a algunos expertos el que no se instale el plug-in a menos que sea totalmente necesario, el problema es que en poco mas de dos semanas Adobe tuvo que hacer tres parches de emergencia para peligrosos bugs, lo cual ha sido en realidad un problema constante durante la vida de Flash. Esto llevó a Adobe a tener que trabajar rápidamente con sus socios distribuidores iniciando el año, dígase Google y Microsoft, para corregir el problema tanto en Chrome como en Internet Explorer de primera mano, pero al final los usuarios tenia que hacer varias actualizaciones del plug-in dependiendo de los navegadores que utilizasen; el problema fue tan grave que incluso Mozilla Firefox desactivo definitivamente el plug-in hasta que hubiera una solución final.

    YouTube abandona el uso de Flash por default en sus videos.

    YouTube, el mayor proveedor de videos en Flash de la historia, anunció que dejaría de servir videos utilizando el plug-in para todos los usuarios que consumen su contenido en un navegador moderno, haciendo por default el uso de HTML5 y su tag . Richard Leider en el blog de la gerencia de ingeniería de YouTube hace una interesante referencia a las razones por las cuales no habían podido hacer de HTML5 su plataforma favorita de entrega de video hasta el momento y de como las cosas han ido evolucionando para HTML5 hasta el punto de poder cerrar brechas técnicas. Esto sin duda marcará la tendencia para otros sitios de video.

    Mozilla y su proyecto Shumway

    En febrero Mozilla y sus programadores activaron Shumway para la reproducción de videos Flash en la plataforma Amazon SIN el uso del Flash Player. El proyecto Shumway ha estado en desarrollo desde hace algunos años y lo que intenta, en pocas palabras, es poder reproducir contenido SWF y FLV sin utilizar el Flash Player, si esto se lograra de forma completamente eficaz y eficiente significaría (desde mi punto de vista) la muerte absoluta e inmediata del Flash Player, sin embargo, el proyecto Shumway no está terminado y aun requiere mucho trabajo, pero lo que ha logrado es bastante prometedor.

    Aquí es donde entra la paradoja y la esperanza para Flash, si bien algo como Shumway al final representaría la muerte inmediata del Flash Player, también significaría darle nueva vida al Flash Professional, la herramienta de creación de Adobe y probablemente a algunas otras que también crean contenido SWF y FLV. La herramienta de diseño y animación Flash Professional per se, sigue siendo bastante buena, trata de ir adaptándose a los nuevos estándares web mientras se mantiene relativamente más accesible que otras herramientas de animación y hoy por hoy aun no existe una herramienta tan buena como el Flash Professional dirigida a el HTML5 puro, el mismo Adobe lo intenta con su Adobe Edge Animate desde hace tiempo pero creo que aun no lo logran.

    Enlaces a las posts previos:

    Flash VS HTML5 Parte 4

    Flash VS HTML5 Parte 3

    Flash VS HTML5 Parte 2

    Flash VS HTML5 Parte 1

    2 Comments
  • User Experience

    Diseño de la Experiencia de Usuario (Parte 1)

    La Experienecia de Usuario siempre ha estado ahí

    La primera vez que programé fue por ahí en la década de los 90s, y entonces desarrollé muchas cosas, de las cuales algunas funcionaban y otras (la mayoría) no o por lo menos no como esperaba, así la mayor parte de lo que desarrollaba en esos años eran solo experimentos para mi deleite personal o para cumplir con alguna tarea escolar. Eventualmente algunos de estos experimentos personales se volvieron más o menos populares entre algunos de mis compañeros de clase, o para decirlo en palabras más capitalistas y emprendedoras, comencé a vender tareas (de las clases de programación y relacionadas) por encargo a algunos de mis compañeros, sin embargo, en las primeras ocasiones en que vendí tareas observé que mis “clientes” no entendían del todo (o en lo absoluto) como utilizar los pequeños programas que les entregaba y me resultaba bastante molesto tener que explicar cómo diablos se usaban, y considerando que tenía que parecer que ellos lo habían hecho, me resultaba un problema. Durante un buen tiempo me la pasé pensando en como podía lograr hacer que mis compañeros entendieran más rápido mis programas.

    En esos años su servidor era un ávido lector de comics, y entonces comencé a meditar en lo hábiles que eran los dibujantes y escritores de estas historietas para dar a entender cosas complejas con tan solo algunos trazos, algunas viñetas bien colocadas o algunos “globitos” con texto, !y entonces vino la epifanía!, rápidamente comencé a observar con más atención los libros ilustrados e historietas dirigidos a niños, adolescentes y adultos, después de un rato de planificación llegué a que debía cumplir con lo siguiente:

    1. Distinguir mis usuarios “tontos” de los “menos tontos” para determinar el grado de esmero para los siguientes pasos (no fuí para nada políticamente correcto).
    2. Asegurarme que mis compañeros explicaran BIEN que era lo que querían para comprenderlo sin ninguna duda (cosa nada fácil).
    3. Ser los más explícito pero breve que pudiera en todos los textos que presentaba (opciones, menús avisos, etc.).
    4. Así como hacían los comics, los juegos y esas raras computadoras de manzana de color, tratar de auxiliarme de colores para contrastar unos elementos de otros y si era posible usar imágenes que respaldaran a los textos (este punto era mi favorito).

    Palabras más palabras menos, esos fueron los pasos que diseñé para tratar que mis “encargos” salieran a la primera, mis compañeros-clientes molestaran menos y obtener un poco de dinero o alimento (tortas, churros, frutsis, .etc) en el proceso. Quisiera decir que todo fue felicidad y viento en popa, pero escribir mis pasos fue más fácil que seguirlos cabalmente, pero sí puedo decir que aunque la lata de mis clientes no desapareció, sí se redujo drásticamente. Muchos años después caí en cuenta de lo que había hecho de manera ingenua, empírica, simplona y corta de hecho tenía un nombre: Diseño de Experiencia de Usuario.

    ¿Pero qué es la Experiencia de Usuario?

    Si usted busca en la web encontrará muchas definiciones, pero para aportar algo con la propia, la “Experiencia de Usuario“, conocida en inglés como “User Experience” y abreviada como “UX” es la manera en que una persona (un usuario) se siente acerca de su interacción con un sistema, tal sistema puede ser un programa de computadora tradicional, un sitio web, una aplicación web o una aplicación móvil entre otros, todo desde luego en un contexto de desarrollo actual.

    La anécdota personal con la que inicié este post fue una feliz coincidencia basada en algo de sentido común, pero en realidad hay gente verdaderamente dedicada al estudio en profundidad del diseño de sistemas pensado en el usuario como el elemento fundamental de cualquier sistema tecnológico, la persona que probablemente ha aportado más en este campo es el Dr. Donald Arthur Norman, un investigador de ciencia cognitiva, diseño y usabilidad.

    El Dr. Norman fue el primero en hablar de manera realmente científica y formal de la importancia del diseño de sistemas centrado en el usuario (user-centered design), lo cual es, en términos generales, la idea de que cualquier diseño de sistema debe estar basado en las necesidades reales del usuario (simple pero profundo cual frase de filósofo chino).

    ¿Porqué es importante la Experiencia de Usuario?

    Usted podría pensar: ¡Pues obvio, si me la paso matándome horas programando para tener contento al #$@&% usuario! pero como diría el Dr. Andrés Roemerno te creas todo lo que piensas“, para nadie en México (donde vivo) y en América Latina es novedad que por lo general estamos un tanto atrasados con respecto a muchas prácticas del primer mundo, donde todo este tema del desarrollo de sistemas centrado en la experiencia de usuario ya lleva un rato tomándose bastante en serio, pero en nuestra región es algo que apenas comienza a cobrar fuerza, es decir, apenas nos estamos dando cuenta de la importancia real de elaborar estrategias, alcances, estructuración, codificación y diseño enfocados realmente en el usuario.

    Antes de que alguien me tire tomatazos déjeme decirle algo, para ver si le resulta familiar, aquellos que llevamos tiempo trabajando en la industria del desarrollo hemos tomado decisiones basados en dos cosas principalmente:

    1. Los elementos e interacciones que construimos en los sistemas son basados en lo que nosotros creemos que funciona. Basamos la estética y la funcionalidad con muy poca idea de como el usuario final usará el sistema, es decir, diseñamos para nosotros mismos (¿dónde está ese documento donde se entrevistaron, evaluaron, cuantificaron, segmentaron a los usuarios finales y sus dispositivos?).
    2.  Todo se elabora en base a lo que el “jefe de alguien quiere ver”. Sucede que todo el trabajo que realizamos está en función del gusto de un individuo con un jerarquía mayor, ya sea de nuestra propia organización o dentro de la del cliente, sí, hablo de ese sujeto que por alguna razón cree ser experto en todo, poseer un sentido común superior y desde luego tener mejor gusto que todos (¿dónde está el documento que dice que ese stakeholder será el único usuario del sistema o si será usuario en lo absoluto?).

    Sin embargo, en los últimos años la Internet y por lo tanto la web ha evolucionado y crecido más en su alcance, los sitios en web se han hecho más complejos y con características cada vez más ricas, y por si fuera poco, hoy en día la gente tiene más medios para consumir información en Internet: teléfonos inteligentes y tabletas con diferentes tamaños y capacidades, más navegadores web junto con diferentes tipos de conexiones, y todo ello nos obliga a tener que utilizar estrategias más inteligentes para lidiar con nuestros clientes y usuarios.

    Otro punto importante es el tema de la accesibilidad, lo cual se refiere a el acceso universal de los servicios y productos basados en Internet para personas con necesidades diferentes (como débiles visuales por ejemplo) o bien para personas que no cuentan con buenos anchos de banda o que aún utilizan dispositivos viejos.

    Tomando en cuenta todos estos cambios, hemos podido observar que todos los productos y servicios que giran alrededor de la Internet y han sobrevivido a lo largo del tiempo son solo aquellos que han logrado adaptarse para seguir siendo útiles y agradables de usar. Así, la moraleja para los que desarrollamos es: todo lo que construimos hoy se convierte en la experiencia que deseamos para con los usuarios que usan lo que hacemos.

    Algunos enlaces de interés:

    Diseño de la Experiencia de Usuario (Parte 2)

    Diseño de la Experiencia de Usuario (Parte 3)

    El Enfoque de la Planeación Agile

    Gamification y LinkedIn

    Estos son alguno libros recomendables para saber más:

    2 Comments
  • Flash VS HTML5

    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

    No Comment
  • Flash VS HTML5

    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

    No Comment
  • Flash VS HTML5

    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

    No Comment
  • Flash VS HTML5

    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

    1 Comment