Muchísimas gracias, no solo por el interés en el artículo si no por la ardua tarea de traducción en colaboración con Alex & Gillian Meldrum ¡Gracias!

Noviembre de 2008.

Que un sitio web cumpla 18 años es decir mucho, es decir siempre. Que lo haga además habiendo sido líder en su sector, prácticamente un monopolio, desde su inicio hasta la actualidad, es hablar posiblemente de la web por excelencia. IMDb es esa web.

Sin embargo, con ese potencial infinito me llama poderosamente la atención lo atrasada que se ha quedado, especialmente en los últimos años, con respecto a sitios que ocupan el mismo lugar en otros sectores. Véase YouTube o Flickr, siendo además estos últimos sitios de muchísima más reciente creación.

¿Dónde estan los feeds? ¡¿Donde está la API?! (¡Se me ocurren tantas posibles aplicaciones!) ¿Para cuando una gestión decente de tus películas y tus votaciones? (la actual es de risa y se remonta al cámbrico internetiano)

¿Para cuando una expansión internacional? ¿O al menos una internacionalización decente que no se limite a traducir los textos estáticos de sus páginas? Lo primero es excusable dado supondría una apuesta arriesgada en cuestiones logísticas. Y es evidente que cualquiera de las dos opciones requerirían de una restructuración bestial de la aplicación. Pero ¿no hay que caminar hacia adelante? Analizando el inmovilismo del sitio con respecto a su larguísima trayectoria, nada indica que pueda haber novedades en ninguna de estas cuestiones, al menos a corto plazo.

(Nota enero 2010: Ya hay expansión internacional. Al menos existe una versión para Alemania, España, Francia, Italia y Portugal.)

Me da la sensación de que IMDb vive en una especie de supuesta invulnerabilidad, al igual que Yahoo hace unos años. Es muy peligroso considerarse invulnerable en internet. Me extraña que nadie haya aprovechado esta relajación de IMDb, porque en realidad el principal valor que atesora es su ingente base de datos, pero, ¿Cuánto se tardaría en re-recopilar toda esa información en la era de la web social? ¿Serían fieles los usuarios IMDbPro a IMDb si otro sitio se llevara la masa social y ofreciera muchas más posibilidades?

Supongo que IMDb pone su inmensa ventaja en juego para, en el caso de aparecer un amago de competidor, echar a correr, pero ¿por qué esperar pudiendo mejorar (=conseguir más volumen de negocio) ahora? No lo puedo entender.

Enero de 2010.

En enero de 2010, poco ha cambiado. Ha habido expansión internacional, se ha creado una App para iPhone, pero en todo lo referente a convertir IMDb en una herramienta de verdadera utilidad para el usuario y en explotar el potencia de su base de datos gracias a una API, como comentaba antes, nanay.

Por contra, descubro que los amigos de La Coctelera hartos de esto se dijeron “hay que hacer algo“. Se pusieron a ello. Y sacaron Partigi. Una web donde puedes hacer todo eso que no puedes hacer en IMDb. Yo ya me he dado de alta ¿Y tú?

Al ver la captura me dio toda la pinta de una inyección de código y que por tanto no debía ser un hackeo. Efectivamente confirmé que se trataba de un problema de XSS derivado, supongo, de la utilización de una versión no actualizada de openCMS, el gestor utilizado en la web, o de un plugin o algo por el estilo.

Desde luego hay muchas cosas lamentables en todo esto, pero si nos ceñimos a lo ocurrido, lo que destacaría por encima de todo, politiqueos al margen, es que no puede ser que una web sobre la que gira tantísimo dinero tenga un problema de seguridad tan burdo.

Lo cual me lleva a una reflexión. No puede ser que en un proyecto en el que se invierten casi 12 millones de euros y que gira íntegramente en torno a una web, se deje una partida residual para el desarrollo de dicha web.

Porque, en definitiva, esto es lo que ha tenido que ocurrir para que acabe pasando una cosa así.

Y no hay que darle muchas más vueltas. Me gustaría saber con qué plazos y con qué medios se contó para el desarrollo.

Es decir. Ocurre lo que ocurre siempre. TODO es siempre más importante que el desarrollo ¡TODO! ¿Los servidores? - por supuesto – ¿El mantenimiento técnico? – claro – ¿La seguridad? - cómo no – ¿La consultoría de seguridad, la consultoría de aquello y de lo otro, el gabinete de prensa, el esto, lo de más allá, las nespreso, los display para la entrada? - Que sí, que sí. Partidas suculentas para todo. Pero, al final, del pastel de 12 millones de euros, después de la vorágine carroñera, cuando queda todo en silencio y del presupuesto solo quedan unas migajas, alguien pregunta: “¿Oye?, ¿Y la web quien la hace?” y alguien siempre responde: “¡Bah! ¡Eso es lo de menos!”

Y ¿Por qué digo esto? Pues porque además de que llevo 12 años dedicándome profesionalmente en España al circo este que es la web, porque lo he visto. He visto como para proyectos muy ambiciosos (como califican a los de pasta gansa) que giran 100% en torno a una web, se acaba llamando al freelance de turno para que él haga la web a semanas de su supuesto lanzamiento. Porque por supuesto, la web era lo de menos.

Algunos enlaces sobre el supuesto hackeo:

• Lo que se comenta en Loogic.
• Lo que sucedió bastante bien explicado.

Los que trabajamos en desarrollo web sufrimos en carne viva la incomprensión derivada de esta visión simplista del concepto diseño.

En España somos, en general, abanderados del simplismo, con lo que no es de extrañar que ocurra así. Lo que sorprende enormemente es comprobar que en un país tan avanzado como Finlandia exista esa misma percepción. Aunque, por supuesto, deduzco que en mucha menor medida.

Habrá a quien le sirva de consuelo, pero a mi particularmente me asusta. Me da la sensación de que el camino que queda por recorrer termina más allá del horizonte. Aunque, desde luego, vendería mi alma al diablo por que en España llegáramos al horizonte nórdico.

Aprovecho para recomendar la serie de artículos Helsinfors Series, by Juan Leal, en los cuales nos cuenta sus experiencias y curiosidades que encuentra en su actual periplo en Helsinki.

Me sorprende especialmente que nadie haya dado ninguna información y explicación del porqué, o los porqués. O de si hay intenciones de que en el futuro se retome, quizá se ha pensado ya en 2010, quizá está todo en el aire.

Supongo que sí, supongo que este no será el fin del evento por excelencia, y con diferencia, sobre web en España. Pero lo que me pregunto es, ¿Qué está pasando? Cómo una nueva profesión, que en teoría no puede estar en ningún otro estado más que en el de crecimiento, se puede permitir el lujo de prescindir de su evento por excelencia.

He oído voces críticas en el sentido de que “ya está todo dicho”, “ya está todo hablado”, “es mejor tal otro evento”. La cuestión es que todas esas argumentaciones son completamente válidas, pero solo de manera individual y para muy determinadas personas. De lo que yo hablo es de todo un colectivo de profesionales. De los miles y miles que se dedican a crear webs en España ¿Es que todos y cada uno de ellos ya se lo saben todo y no necesitan de un evento de estas características? ¡Ja!

Formación y congresos hacen falta como el respirar. Por eso no lo entiendo. De verdad que no lo entiendo.

Aclaración (05/10/2009): La afirmación de que no habrá Fundamentos Web 2009 se basa en la total ausencia de noticias a estas alturas del año. No tengo ninguna información oficial, ni oficiosa, al respecto. Por otro lado, no soy el primero en darlo por hecho, rumorología twittera al margen, creo que es bastante evidente.

¿Qué ocurre cuando una web difunde un código HTML malicioso, o relativamente malicioso, con el objetivo de que otras webs lo incrusten y sin que estas últimas conozcan los posibles consecuencias? ¿A quién hay que penalizar? ¿A la web que origina y difunde el código? ¿A las webs que han picado y lo han usado? ¿O a ambas?

Seguramente es una técnica bastante difundida, pero voy a centrarme y poner como ejempo el caso que he encontrado y analizado.

El caso Trivago

Trivago es un agregador de buscadores de alojamientos que incluye precios y valoraciones de los usuarios de diferentes fuentes (Booking, Expedia, etc)

Si eres propietario de un establecimiento alojativo y tienes buenas valoraciones, Trivago te ofrece una especie de certificado que puedes incrustar en tu sitio web incluyendo un código HTML como este:

<script src="http://www.trivago.com/certificate.php?&amp;item=000001&amp;stats=00001"></script>

<div id="trivago_certificate_000001_00001"><a href="http://www.trivago.com/costa-adeje-31914/hotel">Hotel Costa Adeje</a></div>

El código incluye un enlace cuyo objetivo es posicionar a Trivago en la búsqueda Hotel Coste Adeje (el emplazamiento variará en función del establecimiento). Además, incluye una llamada a un código javascript externo (es decir, que se aloja fuera del servidor del establecimiento) y por tanto un código sobre el que el establecimiento no tiene en ningún momento ningún control.

Cómo funciona.

El código javascript realiza la siguiente acción una vez se carga la página: Elimina el enlace mencionado y lo sustituye por el código final, que es el que hará que se muestre al usuario el certificado personalizado en la web del establecimiento.

Los robots de búsqueda no interpretan código javascript, así que ignoran dicha sustitución y lo que leen es el enlace hacia Trivago. Esto, constituye por si mismo, una técnica fraudulenta de cara a los buscadores, ya que el contenido mostrado a los robots de búsqueda difiere del mostrado al usuario y, además, con un objetivo intrínsecamente malicioso en cuanto a posicionamiento. Como prueba de ello, si el enlace es manipulado o eliminado, el certificado no se muestra. Es decir, Trivago no consiente que se elimine dicho enlace. La mala fe queda demostrada.

El incauto establecimiento es el que hace de intermediario de esta mala praxis y, consecuentemente, como ejecutor, podría ser el perjudicado en caso de que un buscador detectara el fraude.

El engaño es triple:

1. El buscador interpreta que el establecimiento está enlazando (recomendando) la web Trivago para la búsqueda que le interesa a Trivago, en el ejemplo Hotel Costa Adeje.
2. El establecimiento desconoce que poniendo dicho código está incurriendo en una mala práctica que podría significar una penalización por parte de un buscador, lo cual podría implicar incluso la desaparición del establecimiento del buscador con el estrepitoso perjuicio que esto ocasionaría.
3. El establecimiento desconoce que poniendo dicho código está ayudando posicionar una página de Trivago donde, además de aparecer el propio establecimiento, aparece toda su competencia.

Y digo engaño porque ninguna de estas consecuencias directas son advertidas por Trivago, ni tan siquiera en la letra pequeña, cuando propone a un establecimiento que incluya un código con un objetivo aparentemente inocente.

Conclusiones.

Trivago ofrece golosinas a los establecimientos para obtener un beneficio propio en cuanto a posicionamiento. Trivago sabe que las golosinas llevan su dosis de veneno, y que por tanto pueden ser perjudiciales. Los establecimientos pican, porque a todos nos gustan las golosinas.

La moraleja de este cuento es que los establecimientos son mayorcitos y deberían saber perfectamente que no hay que aceptar golosinas de los extraños.

Volviendo a mis cuestiones iniciales. Si un buscador se percata de esta situación fraudulenta ¿Quién debería ser penalizado? Es evidente que Trivago debería serlo por ser la creadora del fraude y quien lo fomenta. Pero, objetivamente, los establecimientos también deberían serlo porque deben entender que han de asumir la responsabilidad que conlleva incuir cualquier código externo que coloquen en sus sitios. Algo que no deberían hacer a la ligera, y muchos menos sin el asesoramiento de un experto.

Lo cual me lleva a un tema mucho más amplio, general y complejo: La autoadministración de sitios por parte de clientes como hipotético paradigma, un tema que trataré próximamente.

El concepto de Acrylic Times (aplicación para Mac) es completamente diferente, pero a la vez muy simple: trasladar esa tarea, que a veces resulta tan agobiante, a un entorno tan relajante como el de ojear un periódico.

La idea es precisamente esa: crear tu periódico con tus feeds favoritos.

El resultado es bastante armonioso y agradable a la vista.

Una característica importante, liberadora de ruido, es que, a medida que vas leyendo entradas, éstas se atenúan (en la siguiente captura puedes apreciarlo).

En la parte superior de la pantalla existe un menú de páginas, donde puedes configurar las páginas que tendrá tu periódico, por temática o lo que desees, cada una con los feeds que quieras.

El layout de las páginas está compuesto por tres áreas, formando tres niveles de jerarquías. Este layout no es modificable, aunque sí ligeramente configurable, pudiendo alterar el tamaño que ocupan los diferentes espacios.

A cada uno de los espacios puedes añadir los feeds que desees (excepto al principal), de una forma muy simple, cómoda e intuitiva. Cabe destacar que la usabilidad de toda la aplicación está bastante bien tratada y la forma de configurarlo todo no podría ser más simple.

Una funcionalidad muy interesante es el shelf (estante). En cualquier momento puedes abrir el estante y arrastar sobre él los artículos que quieres guardar para leer en otro momento, pudiendo formar hasta cuatro stacks (pilas). Una característica muy de agradecer es que puedes configurar el ritmo al que se van eliminando de forma automatizada los artículos del estante. De esta forma no los acumulas indefinidamente, permitiendo liberarte del estrés que supone acumular pilas enormes.

En definitiva, el concepto me seduce mucho y creo que, al menos para mi, puede convertirse en el lector de feeds definitivo.

Solo encuentro dos aspectos negativos en esta versión 1.1 del software:

Rigidez de configuración del layout y del espacio de cabecera. Si bien me parece que es fundamental acotar las posibilidades de configuración del layout, parece que ésta es algo excesiva. El espacio de mayor jerarquía solo permite la inclusión de un feed. Esta limitación me parece excesiva, ya que por temática lo más probable es que tengas más de un único blog de máxima referencia. En caso de que la limitación persista, veo mucho más cómodo poder desactivar ese espacio, quedándote un layout de dos columnas, pero esto no es posible.

Forma en que se ordenan los feeds en los espacios. En el espacio del cuerpo, bajo la cabecera, y la columna derecha puedes incluir tantos feeds como quieras. Sin embargo las entradas se agrupan por feed. Es decir, si te desplazas por el scroll de la columna derecha, verás feed a feed con sus entradas. No me parece una forma natural de ojear las nuevas entradas, ya que te obliga a hacer scroll para comprobar los feeds ocultos por el corte.

Me parecería mucho más lógico que las entradas, dentro de cada espacio, se ordenaran exclusivamente por orden cronológico, no teniendo que realizar ninguna acción para comprobar si hay nuevos artículos.

Esta última cuestión es crucial, al menos para mi, para no lanzarme a la intentona de abandonar NetNewsWire en favor de Times. No obstante, seguiré muy de cerca su evolución para ver si en sucesivas versiones acaba convenciéndome definitivamente.

Me ha encantado este hipnotizante vídeo de Peter Belanger en el que se muestra, en formato time-lapse, el laborioso proceso de creación de una portada de la revista MacWorld.

Una simple foto para cualquiera. Pero un trabajo minucioso, cargado de detalles casi imperceptibles pero imprescindibles, para los que la hacen posible.

Me ha recordado en gran medida a la laboriosidad y complejidad que esconde un desarrollo web, intrínsecamente mucho más complejo (que no se enfaden ni fotógrafos ni diseñadores gráficos), y que ni clientes ni usuarios alcanzan a imaginar.

Recomiendo el vídeo original en formato HD.

La antigua intefaz, bastante tosca y poco atractiva, dejo paso a un nuevo formato con diseño estilizado y reluciente.

Sin embargo, el cambio no me convenció a primera vista, y sigue todavía sin convencerme. Me rechinó en concreto la interfaz circular de desplazamiento.

Aprovecho la noticia de que esta nueva interfaz puede comenzar a usarse con la API, y por tanto que vamos a comenzar a verla en muchos más sitios, para hacer el análisis oportuno.

Mi análisis.

La interfaz original de desplazamiento, que consistía en cinco botones, se fusionó en una única superficia sólida circular en la que aparecen cinco elementos gráficos.

La forma netamente circular de la interfaz no ayuda a indicar cuál es el objetivo de la misma, que es direccional. El concepto de movimiento en cuatro direcciones se diluye demasiado en esta forma circular.

Los cinco elementos gráficos dentro del círculo no se definen visualmente como elementos del todo independientes, ni se antojan particularmente clicables. Tampoco se define de claramente cuál es la superficie clicable de cada uno. Un roll-over tampoco esclarece nada, ya que no existe reacción alguna de la interzaz a colocar el punterodel ratón sobre el círculo. En cualquier caso, no debería ser necesario un roll-over para que estos elementos de la interfaz se identifiquen claramente e indiquen su función.

Para colmo de males, las antiguas flechas fueron sustituidas por dos líneas simples, del tipo mayor o menor o angle brackets (>), formando un ángulo recto. Además, estos cuatro símbolos, por la forma en la que están colocados, hacen que visualmente se fusionen formando un cuadrado (al menos a mi me ocurre). Esa, unión-fusión, favorece a que se cree un concepto de objeto, único, cerrado en sí mismo, “hacia dentro”, en lugar de lo que son y deberían indicar: objetos independientes, que apuntan “hacia fuera”.

Sea como sea, las flechas son elementos mucho más adecuados para indicar dirección.

En conjunto, y en mi humilde opinión, tenemos una interfaz bastante menos usable que la anterior. Más agradable, más armoniosa, pero que define menos claramente su función.

Mis propuestas.

Por supuesto la gente que trabajó en el rediseño de esta interfaz sabe muchísimo más que yo y habrá tenido en cuenta cientos de factores para haber terminado en la interfaz actual. No obstante, me tomo el atrevimiento de hacer mis propuestas de mejora:

Propuesta 1. Se trata de la idea más simple de todas las posibles: combinar el formato de la interfaz original, de cinco botones visualmente independientes, con el estilo de la nueva.

Propuesta 2. Mantener un único bloque con formas redondeadas, para minimizar el ruido visual que generan los cincos botones completamente independientes, pero definiendo más claramente que se trata de una interfaz direccional para generar desplazamiento. Una especie de pad de consola.

Son dos propuestas simples y obvias, pero creo que esta interfaz tan sumamente extendida y con un perfil de usuario tan sumamente amplio (¡cualquiera!), merece dar un paso atrás a esa simplicidad original.

Particularmente me quedo con la segunda, aunque es probable que la primera sea más efectiva, como pienso que era la interfaz original.

Suddenly, lots of XHTML detractors have emerged from their hideouts, most of them, as some realized, like saying “I told you”.

For all those, and some others, I have to say the following:

XHTML has failed in several points.

That’s true.

Has failed mainly in widespreading. It took like 7 or 8 years to reach a point where we could say that most developers were using XHTML.

Has failed also in acomplishing its implicit step-to-XML aim. Lots of people complaint that the whole XHTML thing was a lie because XHTML is mainly served to user agents like html/text.

But.

First. If XHTML widespreading has failed it’s not because the standard itself. It’s because we are working in a profession that moves too fast, with an absolute lack of higher and any other kind of education, and with plenty of new people starting every day to learn web programming with no basis at all, with nowhere to go to learn (did I already say that?), everyone coming from very different fields (graphic design, computing, programming). Everyone self-learning from each other codes, not necesary good examples, in a very anarchic way. An absolute chaos.

Elemental HTML was very easy to understand for everybody. Tags were a few easy “codes” to assign aspect to a content, even far easier with a WYSIWYG tools. Ta-da! Your own web site! That easyness was an open invitation for many to join a new and exciting profession.

But then, new concepts, like separation of content (semantic content), design and functionality arrived. Order arrived. “Huh!”, too much for those who were used to the old way. What happenend then? Plenty of “proffesionals” who arrived precisely because this programming-websites thing was such an affordable task (a bit of photoshoping and a bit of code copy-pasting) were suddenly in a hard position. Now, they should start learning something, really. Did they start looking for a new job? No, not really, well maybe some, but most of them kept doing more or less the same thing for ages. And, as I said before, many more continued arriving to the proffesion and learning from those who already were in it.

To be fair, it was not only inexperienced developers fault. Market was claiming for more and more web designers. Every single company was needing a website. The train was in motion, it couldn’t stop for people to learn so many weird new things. That new stuff could always wait for another day. After all, oldie HTML worked pretty well. Don’t cha think? Where was the problem?

In a so distressing scene, it took what it took for XHTML to take off. XHTML’s fault? Not at all.

But yes, some still claim that the problem is that XHTML is very complex. Well, I find that a huge fallacy. First of all, complex for whom? For non proffesional use there are, and always there will be, tools to easily publish contents in the internet, for everybody. But, for proffesional use, I defend that HTML, or whatever any other script or programming language, has to be as complex as needed to acomplish its goals. Obviously that doesn’t mean that we have to complicate it more than strictly necessary. But we are speaking about a task that is part of a qualified proffesion. If you are not able to understand XHTML or CSS, I’m sorry but then you are trying in the wrong proffesion.

Second. I find the step-to-XML failure argument a bad excuse to generate controversy. It’s true that the final goal of XHTML was supposed to be that. But it’s very demagogic to say that XHTML was a lie just because of that. Because …

… thanks heaven XHTML arrived …

… and broght so many essential things:

Semantics. XHTML was the first standard that deprecated non semantic tags, like b or i. You can consideer that an unimportant detail, but it’s a whole change of vision. Once a developer could understand why b and i old friends were now forbbiden, it could start understanding what semantic means, afterward that understanding he/she could never see code like it used to see it before.

That new vision changed everything. Because, althought HTML 4.01 was pretty close of semantics in intention, it was not 100% semantic. XHTML broke with that. Then, everything started, layouts without tables, spread use of CSS, accesibility, unintrusive javascript, and so on. There was a whole change in the air and everything started growing together. Not only because the arrive of XHTML, of course, but we have to admit that XHTML was in the middle of that huge change.

Order. XHTML brought order in every sense. HTML was permissive with the use of single quotes, double quotes, or no quotes at all for attribute values. That mess ended with the arrive of XHTML. The same happened with lower and capital letters. Lower letters were established for elements and attributes in XHTML. – Oh, come on, Jeremy, how can you say that the indistinct use of lower or capital letters is a question of personal choice? You mean a question of tastes? Please! Remember how code used to be with that permissivity?!

Code is not always for your own personal use. Other people, not just user agents, should be able to read your code. Other people can continue mantaining your work. The same way that safety belt use is compulsory when you drive your own personal car, a minimun strictness in syntax, even for your own personal safety, must be established.

Now again, will we step backwards to that age? Shall we be lenient when, for the first time, things seem to be improving a little bit?

Oh, no! They are coming back!

Some developers that rejected XHTML from the begging, some of them those pseudo-proffesionals I mentioned before (some others of course not), feel now like very brave to proudly claim “I was right, not XHTML, but HTML always was the real way!”? That frightens me a lot. It’s like they were all hidden in caves waiting an oportunity like this to come out with their nasty code.

For those, for whom the important thing was never the code but its result (understanding result as “what is shown in the screen”), what I have to say is: You were wrong before and you are wrong now.

Finally.

It’s true that HTML 5 is supposed to be a continuation of XHTML, removing the X of the XML failed experiment, and adding plenty of new and exciting things, but I find too many gaps in this new way to be happy with that.

I know that most web developers have complaint of the standards development slowness. But, forgetting the fact that standards developers could, in the same way, also complaint of the the standards adoption slowness by web developers, my point is that, after all, good things always need time.

And if we have waited so much for the last brand-new standard, it should be perfect, or almost perfect. But I find so many imperfections so far, specially in semantics and in syntax, that I really can’t hard believe it.

As I said before in my Spanish post about HTML 5: We can’t forget that we are speaking about the standard that will rule in the most important communication enviroment for humanity in the next decades.

It shouldn’t be mistreated, in any aspect, like a trivial thing. And with statements like this I find evident proves that in HTML 5 philosophy there is a bit of slackness in favour of immeadiacy.

For the time being, long live XHTML!

Note: I wrote this article in English in order to reach more people, but as you had already realized I’m not English speaker, my excuses.

Some articles and discussions you should not lose (updated 3/8/2009):

• John Allsopp: Semantics in HTML 5 (6/1/2009)
• Zeldman: HTML 5: NAV ambiguity resolved (13/7/2009)
• Bruce Lawson: HTML 5 is a mess (16/7/2009)
• Jeremy Keith: The HTML5 equilibrium (2/8/2009)