Este es un simple tip para evitar conflictos entre jQuery con otras librerías javascript.

Cuando utilizas jQuery nórmalmente se suele añadir todo el código dentro de la función:

$(document).ready(function() {
// tus scripts
});

Y se utiliza el comodín “$” como sustituto enriquecido del “getElementById“.

El problema surge cuando después de escribir todo el código necesario te encuentras que debes  añadir otra librería, como script.aculo.us, mootools, o Prototype, y debes sustituir todos los signos “$” por otro diferente.

La manera que hasta ahora utilizaba era colocando dentro del $(document).ready(function(){}); lo siguiente:

var loquesea = jQuery.noConflict();

Y donde antes escribía $("#contenido").fadeIn(); debía poner loquesea("#contenido").fadeIn();

Esto no tendría mayor problema salvo que a veces el código sea muy largo o añadas scripts de terceros que no terminas de controlar del todo.

Pues bien, el remedio es rápido y fácil. Hay que envolver la función $(document).ready(function() {}); entre (function($){ y })(jQuery); quedando el script así:

(function($){
$(document).ready(function() {
// scripts
});
})(jQuery);

Sin olvidar meterlo todo dentro de las etiquetas <script type="text/javascript">...</script>

Extraido del slide JavaScript in Drupal 7: What developers need to know.

El problema es el siguiente: si los monitores de sobremesa aumentan la resolución de 72ppp a valores similares a los que se utilizan en impresión, el desarrollador web no tiene herramientas prácticas para que su diseño se escale proporcionalmente a la resolución del dispositivo. (ver conclusiones más abajo)

Los que llevamos años trasteando con la informática vivimos los diferentes saltos de tamaño y resolución de pantallas. Para no irme más allá de los Intel 286, recuerdo que para 14″ la resolución era de 640*480 px. y se podían ver perféctamente los cuatro lados de cada pixel . En 15″ la cosa mejoró a 800*600 px. que todavía sirve como medida standar para ciertos desarrollos web. Luego llegó la hegemonía de las 17″ con sus inmensos 1024*768 px. que el tiempo ya ha empezado a destronar. Y todo esto referido a pantallas de CRT (Tubo de Rayos Catódicos).

la aparición de las pantallas planas supuso subir un paso la resolución con respecto al tamaño del monitor, y así en 15″ ya se pudo disfrutar de 1024*768 px.

Ahora el abanico de resoluciones para dispositivos de sobremesa ha aumentado significativamente, pero siempre guardando una proporción con respecto al tamaño. Esa proporción no es otra cosa que los 72 ppp. (pixels por pulgada).

En medios impresos la resolución estandar es de 300 dpi (dots per inch). de forma que no se aprecian los puntos o los escalonados en lineas diagonales. En pantalla, sin embargo, no son tan evidentes esos defectos y con 72 ppp. se guarda una equilibrada percepción con respecto a la cantidad de información.

Pero entraron en escena los ‘handheld’, dispositivos de mano, móviles sobretodo, que han ido incorporando pantallas cada vez más grandes, tanto que incluso han sacrificado los teclados por sus homónimos en versión táctil. y que además en un afán por mostrar cada vez más información han saltado esa proporción sagrada de los 72 ppp. Sacrílegos!

credit: Jordi Masagué

La palma se la lleva el iPhone 4, que con su Retina Display llega hasta los 326 ppp. Otros ejemplos:

• iPhone: 320×480 | 3.5 in | 164 ppp.
• Palm Pre | 320×480 | 3.1 in 186 ppp.
• Palm Pixie | 320×400 | 2.63 in | 194 ppp.
• T-Mobile G1 | 320×480 | 3.2 in | 180 ppp.
• MyTouch 3G | 320×480 | 3.2 in | 180 ppp.
• HTC Hero | 320×480 | 3.2 in | 180 ppp.
• Motorola Droid | 480×854 | 3.7 in | 264 ppp.
• Nexus One | 480×800 | 3.7 in | 252 ppp.
• HTC Desire | 480×800 | 3.7 in | 252 ppp.
• Nokia N97 | 360×640 | 3.2 in | 229 ppp.
• Nokia N900 | 800×480 | 3.5 in | 266 ppp.

Con ese aumento de resolución se logra más nitidez y definición permitiendo entre otras cosas que las tipografías no pierdan lectura a pesar de la disminución de su tamaño. Pero eso es así por que hablamos de pantallas de entre 3 y 4 pulgadas, que necesitan empequeñecer la información gráfica sin atentar contra la practicidad.

Ahora viene el ejercicio futurológico:

Adelantándome a los acontecimientos, es predecible que la mejora sucesiva del hardware se contagie del aumento de resolución de los dispositivos de mano. Los monitores planos ya son habituales. Los tamaños grandes y extragrandes son asequibles. ¿Cuantas pulgadas tendrá tu próximo monitor? ¿22″, 28″ quizás? El Full HD con sus 1920*1080 px. se convierte en la nueva resolución máxima estandar. Vale, hay monitores con más resolución, pero incluso estos mantienen los 72 ppp. Y además si el propio Youtube se ha preparado para poder servir videos en calidad 4K (4096*2304 pixels) es fácil vaticinar que va a aumentar la densidad de píxeles por pulgada. Calculo 4 ó 5 años para que se implante.

¿Qué pasará entonces si las pantallas de sobremesa aumentan su resolución?

El tema no afecta solo al ámbito informático, si no también al doméstico. Una ‘peli’ full-hd podría verse sin perder un solo pixel en una pantalla de 15″ (o menos).

Enfocando la cuestión únicamente al desarrollo web se dan las siguientes circunstancias:

Los diseñadores web estamos acostumbrados a trabajar al píxel.

Si el píxel se hace pequeño en un dispositivo pequeño nuestro diseño se verá pequeño pero se verá.

Si aumenta la resolución en un monitor de sobremesa, nuestro diseño también se verá pequeño y eso es inadmisible.

Para resoluciones cercanas a las de impresión, diseñar al píxel ya no es tan importante.

¿Hay unidades de medida en CSS porcentuales respecto a la resolución?

NO

Las especificaciones CSS2, en el el punto 4.3.2 Medidas dice claramente:

Si la densidad de píxeles del dispositivo de salida es muy diferente de un típico monitor de computadora, la aplicación del usuario debe re-escalar los valores de los píxeles.

Y el CSS3 no vendrá a salvarnos de momento, por que al menos en ese punto no hay cambios.

Nos tocará añadir un detector de resolución via programación en cliente o servidor y cargar un CSS con las medidas adecuadas, amén de reescalar las imágenes del diseño adaptándolas al ‘pdp’ (piña de píxeles) del dispositivo.

Osea, doble o triple trabajo.

ACTUALIZACIÓN 16/DIC/2011:

W3C tiene en sus especificaciones la versión candidata de CSS3 Media Queries, que permite definir dentro de las etiquetas style o dentro de los archivos css, secciones condicionales según características de los dispositivos de salida.

Por ejemplo, en lo relativo a resolución de pantalla:

<style type="text/css">

#content{ background-image: fondo_100px_x_50px.jpg }

@media screen and (min-resolution: 300dpi){ #content{ background-image: fondo_400px_x_200px.jpg } }

</style>

 

También , los propios dispositivos con resoluciones importantes, léase iphone4, proporcionan sus propias soluciones propietarias:

<link rel="stylesheet" type="text/css" href="css/retinadisplay.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)" >

El futuro se torna interesante.

photo credit: Guillermo Julián

Google está introduciendo de forma escalonada su nuevo sistema para mostrar resultados que denomina Google Instant Search. Consiste en mostrar resultados a medida que se añaden palabras en la caja de búsqueda.
Google lo defiende como un sistema más rápido para que el usuario encuentre lo que busca, pero advierto dos grandes problemas.

1.- Usabilidad
Tengo ganas de ver algún estudio serio al respecto (Jakob Nielsen, ¿estás ahí?), por que la intuición me indica que para el usuario medio debe ser mareante ver aparecer sugerencias de palabras al mismo tiempo que se renuevan los resultados muchas veces y a pantalla completa.

Vale que hayan puesto un link para desactivarlo, pero repito, el usuario medio quedará desconcertado y abrumado por el exceso de información. ¿Por que no lo dejan desactivado por defecto y hacen más visible el botón de activación con una leyenda tipo “PRUEBA NUESTRO NUEVO Google Instant Search“?

2.- Tráfico
El constante refresco de resultados se consigue haciendo peticiones continuas a los servidores de Google que a su vez va devolviendo los paquetes solicitados. Donde antes había una sola solicitud ahora se ejecutan diez veces más. Teniendo en cuenta que Google es una de las páginas más visitadas y por lo tanto responsable de la densidad de tráfico en Internet, esta claro que su nueva implementación podría ralentizar y saturar a la red.

Quizás haya razones técnicas para pensar que esto no será así, que los paquetes de información que mueven son de pocos kbites. Pero al multiplicarlo por las millones de búsquedas que se realizan diariamente con el buscador es evidente que la cifra no es irrelevante.

Eventos relativos al desarrollo web hay muchos durante todo el año. Muchos muy parecidos, pero no conozco ninguno que se parezca al Subflash. En vez de concurrir cientos de personas se cubre un cupo de 60 almas y se busca un lugar con alojamiento e instalaciones para realizar talleres web y compartir experiencias, a precio de risa, aunque lo más destacable es que convives con compañeros de profesión, gurús incluidos, y ya se sabe que el roce hace el cariño.

Después de dos años seguidos en Alicante, asistiendo de oyente, en 2010 se ha celebrado en Bilbao, además coincidiendo con su Semana Grande de fiestas.

Es peligroso hablar y promocionar este evento porque el año que viene pueden haber leches como panes para formar parte de los elegidos, pero ya se sabe que los desarrolladores web somos masoquistas. Si no no se entendería que nos gusta lo que hacemos.

Como cada convocatoría, los talleres son impredecibles y variados. No voy a nombrar a todos los que volví a ver y a los que conocí de nuevos por que soy un perro es un rollo andar buscando nombres y enlazándolos a sus cuentas twitter o web, pero hay una lista completa en la sección Registro de la edición web de este año, y también buscando en twitter con el hastag #subflash.

Repito que lo más destacable es el echo de que al estar todos, ponentes incluidos, alojados en un mismo lugar, aprendiendo, comiendo, durmiendo, etc., durante dos días y medio, es inevitable hacer buenas migas con casi todo el mundo, resolviendo dudas, trasteando gachets, y hablando sin parar de lo que nos gusta.

Queda un año.

Mi galería en Flickr:

Esta es mi pequeña utilidad para adelantar procesos de copiado de texto, pegado y adicción de etiquetas html.

Puedo copiar de word, excel, pdf, etc. y tras pasar por Hachetemelear pegar el resultado en la vista código de un html.

Y sobre todo evito que aparezcan los formatos de word, por ejemplo, o la separación de párrafos con BR.

Es una aplicación sencilla y sin grandes pretensiones. Lo interesante sería poder mantener ciertos formatos como la negrita y la cursiva.

Para la siguiente versión.

Actualización (15/12/2009): Han actualizado a la versión 0.5. En vez del zip ahora solo aparece para descargar el .mxp, pero se puede instalar perféctamente en el DW CS3.

Zen Coding es una utilidad para escribir código más rápido. La descubrí en SmashingMagazine[en] y en Craftyman.net[es] y quise usarla en seguida con Dreamveaver CS3.

El problema es que el plugin que desarrollan está enfocado al Dreamweaver CS4. Puedes ver la lista de todos los programas que tienen más o menos soporte del plugin.

La solución para migrarlo al CS3 es muy fácil.

Cuando descargas la última versión de Dreamweaver, en mi caso la 0.4, el zip contiene el archivo de extensión ‘.mxp’ que instala la utilidad mediante la aplicacion de Adobe Extension manager, y la carpeta ‘source’ con los archivos fuente de la extensión.

Dentro de ‘source’ está el archivo ‘Zen Coding.mxi’. Es un XML que se puede editar, y contiene la línea:

<product name=”Dreamweaver” version=”10″ primary=”true” />

Solo hay que cambiar el 10 por un 9 y guardar el documento.

A continuación pulsas sobre ‘Zen Coding.mxi’ como si fuera una aplicación que quieres ejecutar y se abrirá el Adobe Extensión Manager preguntándote donde quieres guardar el .mxp que se va a generar a partir del .mxi que has modificado.

Y ya tienes la extensión de Zen Coding para Dreamweaver CS3 lista para ejecutar e instalar.

Cuando abras el Dreamweaver aparecerá en el menú ‘Comando’ la opción ‘Expand Abbreviation’. Asígnale un atajo de teclado para que sea una función práctica, si no no tendría sentido.

Por defecto, en la documentación de la utilidad, se usa [Ctrl+,] (Control más coma), para lo cual en Dreamweaver habrá previamente que eliminar el atajo de teclado para la función ‘Anular sangría de código’ que está en la opción ‘Edición’ de la barra de menú.

El plugin todavía está en desarrollo pero ya se puede disfrutar de su magia.

Lista de abreviaturas soportada parcial o totalmente: Zen HTML Elements, Zen HTML Selectors, y Zen CSS properties.

Descargar/download:  Zen-Coding_DW-CS3.zip

Barra Sidewiki

No lo he probado, por que no me interesa. Se trata de un sistema mediante el cual e instalando una extensión en tu navegador, puedes comentar acerca de una web, y ver otros comentarios,  pero sin el control del dueño de esa web, aunque si con el control de Google. Aqui hay más información de Google Sidewiki (en inglés).

La queja viene de los creadores o gestores de contenidos que ven como se puede desviar el posible feedback fuera de su dominio, y en consecuencia perder el control sobre la conversación con los usuarios, amén de recortar el “share” de aportaciones y descentralizar el “feed” de comunicación. Completamente de acuerdo. Y además es que Google se convierte en el gestor de esos comentarios paralelos, ordenando y eliminando según su criterio algorítmico y fuera de la linea editorial del sitio.

También es verdad que para algunas páginas que no contemplan, o han eliminado, la opción de comentarios, el Sidewiki puede venir muy bién. Me viene a la mente el dominio principal de Microsiervos que creo recordar eliminaron el formulario para comentar debido al problema de revisar el insufrible Spam.

Atando cabos pienso que el Google Sidewiki podría ser una herramienta sensacional si se crearan sistemas para incorporar esos comentarios a los que vienen por defecto, siempre y cuando al propietario del sitio se le permita tomar ciertas decisiones, como refiltrar los contenidos ya filtrados de Google, reordenarlos también, o aportar posicionamiento en función de cantidad y relevancia, y al fin y al cabo mezclar lo propio con lo ajeno.

Y una cosa más, si el control de spam de Gmail funcionara igual en Sidewiki, algunos cancelarián en seguida los sistemas propios de comentarios.

(Si comentas esta entrada con Sidewiki recuerda que solo los usuarios que también  lo instalaron podrán ver tus opiniones, pero si lo haces desde el propio formulario de Saltarintro, todo el mundo lo verá. )

Se nos quemaba el arroz a los desarrolladores web de Alicante. Menos mal que algunos son más inquietos que otros y no paran ni en boxes. Y así ha nacido ADWA, Asociación Desarrolladores Web de Alicante.

Este jueves 1 de octubre, deberías acercarte al CAMON para ver la presentación oficial. Y es lo mismo si eres freelance, trabajador por cuenta ajena, intrusista, diseñador o programador.

Si algo ha caracterizado al sector web en general es que somos demasiadas mentes independientes que nos vemos de tarde en tarde cuando hay algún evento, para después volver cada uno a su redil, y a su particular percepción de la realidad web.

Es muy importante para estar al día conocer lo que demanda el mercado, lo que sale de los laboratorios I+D, las tendencias en tecnologías, frameworks, lenguages, técnicas, puf…

¿Querías vivir haciendo páginas web? Pues te toca estar al día. Creo que no es muy habitual este tipo de asociaciones en otras provincias asi que es para no dejar pasar la ocasión.

A veces en mi trabajo me ha tocado hacer entrevistas a futuros compañeros de curro, y me he encontrado con desconcertantes faltas de conocimiento en tecnologías que aunque no se usen hay que saber al menos que existen.

Que sepas que ADWA ya ha conseguido también ser Adobe User Group. La cosa va en serio.

Asi que si quieres hablar de esos temas que nos apasionan pero que no puedes hacerlo con tu pareja o amigos por que te miran raro, ya sabes.

En CAMON el jueves a las 19:00. Date de alta en la página y apúntate a la presentación. Las plazas son limitadas, y no, no me dan comisión.

photo credit: justinsomnia

¡Google lo vueve a hacer!

El día de los inocentes (April Fool’s Day en Reino Unido y Estados Unidos) del 2004 sacó a la palestra su Gmail con su almacenamiento ‘Gibante’ y creciente, y sobre todo con Ajax, una tecnología característica y clave de la web 2.0, que hasta ese momento no había sido explotada. Y vaya si explotó. Desde ese momento el poder actualizar datos sin recargar las páginas casi es materia obligada.

Concretando. Google rescata el Ajax usándolo de forma magistral en una aplicación de correo, y a partir de ese momento todo el mundo descubre sus bondades y comienza a utilizarse.

El antes y el después del Ajax se llama Gmail.

Y ahora otra tecnología renace de sus cenizas, también de la mano de Google.

El antes y el después del HTML se llama Wave.

No hablaré de Google Wave que ya hay demasiada información por ahí, pero si sobre algunos acelerones impredecibles que se dan en desarrollo web.

En 1999  la W3C hizo pública la última revisión del HTML, la 4.01, la v.4 salió dos años antes. En esos momentos también se desarrollaba el XHTML como el paso siguiente, y que vería la luz en versión 1 en el 2000.

El XHTML es básicamente un XML con un DTD que cubre las etiquetas revisadas del HTML pero bajo una especificación más extricta en la sintáxis, lo cual lleva a la correcta construcción del DOM y por lo tanto permite la construcción sólida y fiable de aplicaciones web y comportamientos avanzados en javascript.

La evolución del XHTML pasa por su versión 2, que en la actualidad está en desarrollo. En el 2004 el Web Hypertext Application Technology Working Group (WHATWG) empezó a desarrollar el sustituto del HTML 4.01 como versión 5.

Y las dos líneas han ido paralelas con sus fans y detractores desde entonces. En el 2007, la W3C empezó a colaborar junto al WHATWG en HTML5, y a lo largo del tiempo la tecnología que parecía más lógica en la sucesión (el XHTML2) se ha quedado atrás en favor de la que parece más popular entre desarrolladores, el HTML5.

Pero todo indica que como Google ha abrazado el HTML5 abiertamente, haciéndolo rendir bajo su nueva aplicación Google Wave, en el momento en que salga de su beta privada a beta pública, como no, y además será este mismo año, parece claro que por narices los navegadores tendrán que añadir la interpretación de HTML5, y se empezará a usar (y abusar) de sus carácterísticas, aunque todavía no llegue a Versión Candidata a Recomendación. Juas.

Todo esto será muy positivo. Supondrá una actualización del parque de navegadores para que puedan soportar la nueva especificación (las versiones más modernas, o en beta, de el IExplorer, Safari, Firefox, Chrome, u Ópera ya lo hacen parcialmente).

Se mejorará la compatibilidad con estándares, por que el parque de navegadores obsoleto bajará drásticamente.

¿Pero que le pasará al XHTML2?

Que no se convierta en un Betamax el tiempo lo dirá.