Max Villegas Viviendo en la era digital

En resumen, Prism es otra aproximación más a esto de las aplicaciones web como escritorio bajo el alero de la cloud-computing, es decir, es la apuesta de Firefox para competir contra Adobe Air y Silverlight.

En mi opinión, la ventaja que tiene Prism por sobre la otras alternativas es que al ser una especie de fork de Firefox ya está diponible en todos los Sistemas Operativos, vale decir, Windows, Mac  y Linux, tanto en versiones de 32 como de 64 bits.

Además, a diferencia de Air y Silverlight, Prism no pretende crear una web alternativa sino que intenta extraerla del navegador para llevarla mediante XUL a nuestro escritorio.

Esto significa que pueden desarrollarse aplicaciones web haciendo uso de tecnología y lenguajes conocidos: HTML, JavaScript, CSS, etc y que, en favor de la convergencia, más vale crear aplicaciones  minimalistas que realicen funciones específicas, puesto que pueden (re)utilizarse tanto en dispositivos móviles como en widgets de manera independiente de la plataforma y del Sistema Operativo, con una reducción de costos en tiempo y dinero que puede ser sustancial.

Más información

• https://wiki.mozilla.org/Prism#Web_Application_Script
• https://labs.mozilla.com/forum/?CategoryID=16
• http://es.wikipedia.org/wiki/Artilugio

Si dependiera de los internautas de todo el mundo Obama sería electo Presidente casi sin ninguna resistencia, es que Barack Obama ha usado Internet de manera excepcional tanto para comunicar su mensaje como para posicionar su nombre y su imagen como una marca imposible de olvidar…

Por eso no me gustaría ni pensar lo que pasaría si votara por McCain

Hace rato que uso la librería jQuery por lo que me resulta súper fácil manipular elementos HTML por su su clase, independiente de su tagName (a, div, span, etc). Por ejemplo en una breve y simple líena puedo darle display:none a todos los elementos con clase hide:

//lo simple es bello
$(’.hide’).hide();

En Prototype (que no ocupo desde que comencé a usar jQuery), aunque era un poco más complejo y limitado, tampoco daba muchos dolores de cabeza:

//Sólo hay que dominar bien los selectores tipo CSS de Prototype
$$(’div.hide’).invoke(’hide’);

Incluso era posible de esta forma:

//iteramos sobre cada elemento
documetnt.getElementsByClassName(’hide’).(Element.hide);

Pero resulta que la función getElementsByClassName() aún no es un estándar (lo que significa
que obviamente no funciona de froma nativa ni en IE6 ni en IE7, pero sí en Firefox3, Safari y Chrome), por
lo tanto, para que funcione en IE debe estar soportada por la librería que ocupemos.

En el caso que estemos trabajando sin ninguna librería o que no esté soportada (por ejemplo en las versiones nuevas de Prototype está obsoleta), la podemos implementar fácilmente con el siguiente código:

document.getElementsByClassName = function(cl) {
var retnode = [];
var myclass = new RegExp(’\\b’+cl+’\\b’);
var elem = this.getElementsByTagName(’*');
for (var i = 0; i < elem.length; i++) {
var classes = elem[i].className;
if (myclass.test(classes)) retnode.push(elem[i]);
}
return retnode;
};

Referencias:

• http://www.prototypejs.org/api/utility/getElementsByClassName
• http://www.anieto2k.com/2007/05/29/ultimate-getelementsbyclassname-mejorada/
• http://edusanver.wordpress.com/2007/10/03/getelementsbyclassname-javascript/
• http://www.anieto2k.com/2007/02/03/firefox-3-integrara-getelementbyclassname/

Tengo mucho código para postear, pero me aguantaré unos días para hacerlo detalladamente en blogandia. Ahora sólo quiero sacrame un poco las ganas de hablar de JSON.

Algunas de las razones porque vale la pena trabajar con este tipo de notación son:

1-. Por sobre todo: orden. Trabajar javascript con JSON es por lejos más ordenado y simple que hacerlo de la forma clásica. A este orden “visual/mental” hay que agregar un punto tan o más importante que mi manía personal por el código elegante y ordenado: los nombres de las variables y funciones dificilmente interfieren con los nombres de variables y funciones de otras aplicaciones javascript que coexisten generalmente en un sitio web.

Por ejemplo, es perfectamente posible el siguiente escenario:

var aplicacion_uno = {
cargando : function(){
//código de esta funcion;
},
hide : function(){
$$(’ul[class=hide]‘).map(function(s){$(s.id).hide();});
}
}

var aplicacion_dos = {
cargando : function(){
//código de esta funcion;
},
hide : “se traduce como esconder”
}

2-. Para trabajar con gran cantidad de datos dinámicos de forma asincrónica es mucho más rápido que hacerlo con XML, en pruebas preliminares con firebug, para la siguiente consulta el tiempo de respuesta es de 164ms.

[{"modelo_generico":"Chevrolet Corsa","t1":"25.800","t2":"21.900","t3":"17.955","t4":"15.750",
"zonal":"RENT A CAR ANTOFAGASTA","patente":"WV-9955","fecha_inicio":"2007-12-05",
"fecha_termino":"2007-12-15"},
{"modelo_generico":"Chevrolet Corsa","t1":"25.800","t2":"21.900","t3":"17.955","t4":"15.750",
"zonal":"RENT A CAR ANTOFAGASTA ","patente":"WV-9960","fecha_inicio":"2007-12-15",
"fecha_termino":"2007-12-20"}]

Mientras que para una cantidad evidentemente menor de datos en xml la respuesta menor que he obtenido es de 544ms.

<xml>
<contenido>
<status>ok</status>
<precio>45000</precio>
<pasajeros>1</pasajeros>
<dolar470</dolar>
</contenido>
</xml>

3-. Si bien la forma de pasar los datos de un lado a otro es básicamente la misma para JSON y XML (Ajax.Request o $j.ajax con prototype y jquery respectivamente), la disponibilidad de ellos es radicalmente distinta. Mientras que con XML hay que parsear los datos según las etiquetas:

xmlparse : function(responseXMLCli){
var xml=responseXMLCli.responseXML.documentElement;
var item=xml.getElementsByTagName(’contenido’)[0];
var pasajero=item.getElementsByTagName(’pasajero’)[0].firstChild.data;
alert(pasajero)
}

con json quedan disponibles de inmediato

jsonready : function(data){
alert(data.pasajero)
}

Un DTD especifica los tipos de elementos y atributos que podemos utilizar en una página web; define, de acuerdo a la especificación del lenguage de marcado, las reglas de cómo podemos usar estos elementos juntos y, también, declara cuáles juegos de caracteres debemos usar.

Los validadores comprueban que una página web esté correctamente escrita de acuerdo al DTD especificado en la declaración DOCTYPE, utilizando el identificador del sistema o, implicitamente, usando el identificador público. Sin embargo, los navegadores actualmente usan intérpretes que no validan y no leen el DTD.

¿Cuales son las diferencias entre los DTD?

Por ejemplo, para el HTML 4.01 existen 3 tipos de DTD:

• Strict, el DTD “HTML 4.01 Strict” hace énfasis en la separación del contenido de la presentación y el comportamiento. Este DTD es el que la W3C recomienda para todos las páginas web actuales. Este DTD es recomendado por sobre el HTML Transitional y Frameset.
• Transitional, el DTD “HTML 4.01 Transitional” significa que puede ser usado transicionalmente para convertir un documento de las versiones anteriores de HTML 4.01 en uno más moderno, no es recomendable para nuevas páginas web. Este tipo incluye 11 tipos de elementos que estás obsoletos pero que se pueden usar.
• Frameset, el DTD “HTML 4.01 Frameset” se utiliza para página que usan marcos. debes tener en cuenta que los marcos son obsoletos fueron descotinuados por la W3C, se recomienda que en este caso se utilice algún scritp del lado del servidor para reemplazar los marcos.

En el caso del XHTML 1.0 se deifnen los siguientes tipos:

• Strict, se usa cuando se desea un lenguaje de marcado limpio y se usa en conjunto con las hojas de estilo CSS.
• Transitional, se usa cuando se necesita de ciertas características del HTM y cuando se quiere dar soporte a navegadores que no entienden las Hojas de Estilo.
• Frameset, se usa cuando se necesitan los framset de HTML para dividir el nagvegador en dos o mas recuadros.

¿Cuál DOCTYPE debo utilizar?

Hasta donde sé, no hay una recomendación oficia,l o al menos no la pude encontrar en la W3C. No obstante, al ser el XHTML la evolución natural del HTML4, y por su tendencia a ser un lenguaje de marcado más semántico que su antecesor, es recomendable usar el DTD XHTML 1.0 Strict.

Sin embargo, actualmente se está a la espectativa de lo que sucederá con XHTML2 y el HTML5, debido a que Tim Berners-lee escribió un post donde asumiendo el fracaso en cambiar a la gente al XML y anuncia la formación de un nuevo grupo de trabajo encargado de mejorar el HTML, lo que ha generado debate entre los desarrolladores y especialistas.

vía

Las solapas o pestañas son muy utilizadas en prácticamente todos los sitios que se ven hoy en día. Jacob Nielsen (para el que no lo conoce para muchos el “guru” de la usabilidad web) ha escrito 13 reglas para hacer las solapas usables.

1. Utiliza las solapas para moverte dentro del mismo contexto y no para navegar por áreas diferentes

2. Utiliza de manera lógica porciones de contenido para que los usuarios puedan predecir fácilmente que encontraran cuando selecciones una solapa.

3. En línea general los usuarios no tienen que ver de forma simultanea el contenido de múltiples solapas. Si la gente realmente tiene que comprar la información entre diferentes pestañas la necesidad de ir hacia delante y hacia atrás pone un carga extra en su memoria a corto plazo y de esa forma baja la utilidad comparada con un diseño que pone todo en una sola página grande.

4. Las pestañas son paralelas por naturaleza, al menos para los usuario de los Estados Unidos (Para los usuarios internacionales sería mejor tener una pestaña para “Norteamérica” o “América” para un mejor paralelo con “Europa” y “Asia”)

5. La pestaña que se encuentra seleccionada tiene que estar destacada. Puedes destacarla por su color, por un tipo de fuente distinta o bien haciendo aparecer esta solapa delante de las demás.

6. Las solapas que no están seleccionadas deben estar claramente visibles, un color que se confunde con el fondo puede lograr que el usuario nunca pulse en ellas y por lo tanto nunca conozca su contenido.

7. La solapa común y corriente esta conectada con el área que posee el contenido, de igual manera que miramos en las tarjetas de un índice físico. Esta conexión ayuda al usuario a visualizar las solapas activas y reforzar la conexión entre el contenido y su solapa.

8. Las solapas deben contener texto corto y con un lenguaje simple. Las solapas en general deben contener una o dos palabras. Las solapas cortas son mas “escaneables” si necesitas solapas más grandes esto es un signó que las opciones son demasiados complicadas para este tipo de control.

9. Mantener siempre un mismo estilo de capitalización. En este punto Nielsen no recomienda poner todas las letras en mayúscula cuando definimos el texto de cada solapa puesto que dificulta la legibilidad.

10. Utilizar solo una fila de solapas. Muchas filas destruyen la memoria espacial y hace imposible a los usuarios recordar que etiquetas ya han visitado. También muchas filas de solapas son un síntoma de complejidad excesiva. Si necesitas más de una fila de solapas tiene que simplificar tu diseño.

11. Las filas de solapas deben estar arriba del panel y no sobre los costados ni abajo, lugares en donde seguro pasaran desapercibidas.

12. El alcance de uso de las pestañas o el área que controlan debe estar claramente definidos en el aspecto visual.

13. Velocidad de respuesta. Al presionar sobre una etiqueta el contenido deberá ser desplegado de manera instantánea, probablemente se logre esto con Ajax, no obstante la tecnología no es lo importante, sino mas bien el resultado. Es aconsejable que el tiempo de respuesta sea menor a 0.1 seg.

En Denken Über me entero de un post de Marc Andreessen sobre las plataformas de internet. Andreessen definde el concepto de plataforma de manera muy simple:

A “platform” is a system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.

En definitiva, si el sistema es programable por otros desarrolladores y usuarios es una plataforma, de lo contario, no lo es”.

Además distibgue 3 tipos de plataformas:

1- API de acceso a datos: donde solamente podés tomar datos y armar algun tipo de mashup o visualización de los mismos. Ej: Flickr, eBay, Paypal
2- Plugin API: la que te permite crear nuevas funciones o extender las ya existentes a través de código “montado” sobre la plataforma (inyectado) Ej: Facebook F8
3- Runtime Enviroment: es la plataforma donde el código creado por los desarrolladores externos core DENTRO de la plataforma. Ej: Second Life, Ning, Salesforce

Es un post muy intersante sólo habla desde lo técnico sino que además manifiesta que la tendencia en Internet será utilizar las plataformas Runtime Enviroment.

Volviendo un poco sobre mi post 5 errores en los contenidos de un sitio web me encuentro hoy un post en Linux Today sobre un formato público, abierto y estándar para los contenidos de noticias online.

The News Industry Text Format is an XML-based format used by the news industry to encode and share the content of news articles. PEAR’s XML_NITF package provides an extensible API to read and parse NITF-formatted files, making it easy to extract bibliographical information and article content for use in any PHP application.

Me pregunto si en La Tercera o en LUN sabrán de esto… ¿Qué creen?

Es interesante ver cómo de un lado del mundo se discute sobre el futuro del periodismo (vía jbarahona) y se entiende que Internet juega un papel vital en su construcción; mientras por acá parece que nos quedamos pegados en la era de la fotocopiadora.

Si quieres saber más sobre NITF:

• Read News Industry Text Format (NITF) files with PHP
• NITF Website
• NITF tutorial
• NITF specification

En Content Matters publicaron un post en el que describen 5 errores básicos referente a los contenidos de un sitio web, que en resumen los interpreto, porque traducir literalmente no funciona siempre, en la siguiente lista:

1. El contenido no es diseñado (organizado) para la web
2. El contenido es publicado en la web porque se puede, no porque se debe
3. Falta de una línea editorial definida que oriente el criterio de los redactores.
4. No se trabaja con procesos ni estándares de calidad
5. Los contenidos web no son valorados

Enlace: Five basic mistakes with website content

Hace rato que quería postear sobre este tema. Primero, por la valiosa ayuda que significa contar con buenas herramientas de desarrollo y, segundo, porque Firefox es un tópico que me trae hartas visitas. Además, justo ahora me sirve para secundar un post de Darcy referente a una conversación que tuvimos sobre lo extraño que nos parece el temor que sienten algunas empresas por el hecho de que sus ideas sean copiadas… Uff! Si es la mejor forma de liderar en Internet. Por ejemplo, ayer investigaba nuevamente sobre las Conversaciones Distribuidas -un tema que me obsesiona- y llegué a la wiki de Microsiervos sobre el tema. Wow! Hace dos años todo estaba muy en pañales, pero ahora ya hay tres sitios que capitalizaron la idea y aún así la pelota sigue dando botes. ¡Qué enseñanza, no?

Aunque este es un tema bastante menor en comparación al ejemplo citado, espero sirva de base para una conversación interesante entre dearrolladores y bloggers sobre la materia. El caso es que en AV todos los sitios que producimos son testeados en Safari, Explorer 6/7, Opera, Firefox y Konqueror, no obstante el grueso del desarrollo se hace usando Firefox. No es casualidad, pues resulta que este browser cuenta una ventaja enorme para el desarrollo web, debido a la gran cantidad de extensiones que tiene para este efecto.

Finalmente, las 7 extensiones imperdibles para un desarrollador web son la siguientes:

1. Web Developer Toolbar
Es imperdonable si eres desarrollador y no la usas. Su utilidad sobrepasa todo lo que pueda decir de ella. Tal vez lo único que le falta es un cuentagotas, pero sólo por sus atajos de teclado para ver el código fuente o para pillar ese nodo html que necesitas para darle style o manipularlo vía Ajax es el “number one” de esta lista.

2. FireBug
Otra extensión obligatoria si desarrollas. Debo confesar que la uso desde hace poco, pero me ha sacado de apuros con javascript más de una vez. Aunque su utilidad se extiende también a CSS y HTML.

3. FireFTP
Es un cliente FTP que no tiene nada que envidiar a niguno de los más populares como CuteFTP o WSFTP. Soporta SFTP, conexiones pasivas y activas, sincronización entre la carpeta locales y del servidor.

4. Dom Inspector
Dependiendo de las opciones que selecciones, se instala junto con Firefox. Tremendamente útil para trabajar con Ajax, sobre todo, cuando te peleas con Explorer o Safari.

5. Tab MixPlus
Imperdible cada vez que instalo Firefox. Tal vez no es tan útil como las anteriores, pero me permite configurar las pesetañas, el comportamiento del mouse y la sesiones a mi antojo.

6. Colorzilla
Es el cuenta gotas que le falta a Web Developer, muy útil para trabajar en CSS y diseño en general.

7. Del.icio.us Bookmarks by Yahoo Inc.
Constantemente navego buscado tutoriales y guías que si no fuera por Del.icio.us y esta extensión se perderían en el olvido. Lo mejor es que tanto en mi casa como en mi trabajo tengo los mismos bookmarks. Si los necesito en otra parte, además los tengo integrados a mis blogs y a mi facebook.

Entonces ¿qué extensiones utilizas tú?