Estos días todos estamos más contentos que de costumbre (si eso es posible ). Todo son fiestas y reuniones; Sidra, Cava, Turrón y Polvorones por todas partes e inclusive podemos llegar a aumentar algún kilo si no nos cuidamos.

Es una fecha especial para los comercios (no words) y las tarjetas de crédito. Donde algunos se quejan de lo comercial que se ha vuelto todo y otros sólo piensan en la lotería.

En fin, para nosotros es un momento muy bonito del año. Nos encanta la navidad y todo lo que involucra. Así que a todos ustedes, Feliz Navidad!! Feliz Hanukkah (en honor a mi abuelo).

Últimamente no he hecho más que oir hablar de AJAX. AJAX por aquí, AJAX por allá, que si esta aplicación lo usa, etc… pero creo que a mucha gente se le está escapando de las manos.

No debemos olvidar que, si bien es una tecnología con el potencial de mejorar la experiencia del usuario web, entraña ciertos problemas (algunos ya resueltos) que pueden empeorar la usabilidad y accesibilidad de un sitio, sin entrar en las consideraciones del soporte multinavegador. Con esto no quiero decir que la tecnología sea mala de por si, ni mucho menos, solo que algunos desarrolladores deberían tener en cuenta factores.

Uno de los errores más comunes que he podido encontrarme es la de generación de páginas web a través de esta tecnología a partir de un CMS, manteniendo el layout y cambiando solo el contenido. Si bien es una práctica que supuestamene reduce el tráfico (ya que solo recarga la parte que cambia) tiene varios problemas de base:

• Rompe con el esquema de página como unidad independiente de información
• Deshabilita la navegación mediante los botones del navegador (página anterior y siguiente, recargar, etc…)
• Imposibilita el acceso directo a la página y su guardado en marcadores (ya que la URL jamás cambia)
• Al cambiar el contenido sin haber un refresco de la página algunos dispotitivos de acceso web (lectores de pantalla, braille, etc…) podrían no ser avisados de los cambios, con lo que el usuario no accedería jamás al contenido más allá de la página principal.

Sin embargo si que he visto usos muy, muy buenos de esta tecnología, en general usándola para mejorar la usabilidad de widgets como la subida de archivos de Gmail, la navegación por un calendario en un panel lateral sin refrescar la página o algunas páginas de búsqueda de productos o ítems, en las que se puede filtrar en vivo los criterios que escoje el usuario e incluso su uso para animar elementos de la página.

Todo esto, por supuesto debería userse de forma no intrusiva, y permitir el acceso a dichas funcionalidades aun sin AJAX activado. Ya se han propuesto varias soluciones para algunos de los problemas expuestos en este post, y cada día veo una aplicación nueva para esta tecnología, algunas realmente innovadoras y otras no tanto.

Sin embargo, y hasta que madure algo más, pienso que la usaré solo para mejorar, de forma no intrusiva la experiencia de nuestras aplicaciones, mediante widgets o sistemas de búsqueda/filtrado.

Hola a todos. Llevo algo de tiempo sin escribir porque he estado ocupado con el desarrollo de Canarias Orgánica y el análisis de otros proyectos que tenemos sobre la mesa.

Esperaba tener la página funcionando, al menos a un nivel básico, esta semana, pero he preferido tomarme otra semanita más para poder comprobar que lo que estoy haciendo cumple con mis espectativas, que suelen ser muy, muy exigentes . De momento he logrado simplificar la estructura del sitio bastante, pero quiero hacerlo aun más.

La idea básica es que el código sea lo más simple posible, y lograr que la página degrade bien incluso si se ve sin imágenes sin CSS (es decir, texto puro sin formato). Pero para lograr algunos de los efectos visuales del diseño es necesario añadir marcado que, si bien no altera la semántica, tampoco aporta nada, así que estoy pensando añadir este marcado mediante Javascript no intrusivo y DOM, usando una hoja CSS para versiones con javascript y otras para navegadores no compatibles más sencilla. De esta forma creo que mejoraré la accesibilidad del sitio, una de mis mayores preocupaciones en este momento.

Lo único malo de esto es que tengo que reescribir prácticamente todas las plantillas de Xaraya que utilizo para adecuar el código. De todas formas en un post posterior empezaré mi análisis sobre Xaraya con pequeñas cosas que me he ido encontrando y que podrían mejorarse.

Nos leemos.

En casa contraté Imagenio por curiosidad, siendo un amante de la tecnología y de los dibujos animados parecía una alternativa interesante a Digital plus (y venía el ADSL).

Al principio todo genial, lo que me animó a convencer a mis socios en OrgánicaDTM para contratarlo, ya que al trabajar con dibujos animados e ilustraciones nos pareció buena idea contar con la gama de canales infantiles que ofertaba Imagenio.

Al mes de solicitarlo, nos llamaron de Telefonica (sin tilde…) para decir que tardarían un mes más en instalarlo. Dando la casualidad que esos mismos días acababa de llamar al 902 para reportar una avería en el de casa (la imagen se congela cada pocos minutos).

Todas las semanas llamaba al 902 y me decían que en 24-48 horas se arreglaría… no se arreglaba y al volver a llamar habían cerrado la incidencia anterior, ya que lo hacen de forma automática sin consultar al cliente.

Conclusión: Sigo esperando para que arreglen la avería (pensando en dar de baja el servicio, después de revisar en foros varios toda la gente que tiene el mismo problema); cancelé la instalación de Imagenio en la oficina; no recomiendo a nadie que contrate el servicio hasta dentro de un tiempo, cuando sepan como funciona bien la tecnología (yo acepto ser Betatester, pero no al precio de un servico 100% operativo).

El panorama para el usuario después de leer los cientos de clientes que manifiestan sus problemas y como las grandes telecos los ignoran no es de lo más alentador. ¿Quizás alguién podría pensar algún sistema tipo FON pero orientado a la televisión? ¿Será quizás el modelo de Apple y las cadenas norteamericanas el principio de un cambio? ¿El videoblogging podría ayudar a mejorar los servicios? ¿Es justo que mientras yo discuto sobre estos problemas en España en otros muchos lugares su mayor preocupación sea cómo sobrevivir? Nunca pensé que el tema de Imagenio diera para tanto…

SOLUCIONADO: Tuve suerte, el fin de semana después de mi última queja y publicación del post, fue un técnico por casa y estuvo viernes, sábado y domingo sin parar buscando la solución. Además era simpático y explicaba todo con detalle y sin problemas… como dije, suerte que fue Sergio el técnico simpático y que sabía bien cómo funcionaba Imagenio.

Espere varios días antes de publicar que se solucionó todo (cambio de router y reseteos varios) para estar seguro. Saludos y espero no tener que volver sobre el tema

First of all, i’m not a core developer, but i’m working hard on some areas and use Xaraya extensively. These are my ideas as a developer, theme creator and admin of various Xaraya installs.

I’ve read John Cox and Marcel’s posts and i’m very pleased to see that they think more or less about same thing as me, but I have some additional ideas.

Following John’s idea of using templates to manage all GUI functions and all my recent work to get a full MLS in Xaraya (for gui and content) I would like to propose a very radical idea: split off MLS, at least as we know it today. Yeah! I know, it sounds very radical, but i’ve very good reasons and solutions for all problems I’ve found, and i’ll try to show you how.

Localization of templates

First use of MLS is localization of interface into diferent languages, through xml files and blocklayouts tags.

Is well know that this paradigm slows down the whole system, and the only solution is delete all <xar:ml*>tags</xar:ml*> in templates and translate all strings, usually overriding module templates. But there is a problem. A lot of modules have diferent strings hardcoded in api or user functions, and if you want to have it translated you must use actual xml system.

But, if all display content is going to be rendered with templates, like John proposed, the need of a xml translation file is dead. All translations could be done directly in theme files. Now someone could see some problems:

It’s more work to translators!

No, it’s the same work, even best. My reasons are:

1. If you create a new theme, you must translate all new strings, and the only work you can reuse are modules and core templates translation (if you doesn’t customize it). If you override all module and core templates, you only need to do it once, and reuse in every theme you create.
2. Sometimes is hard to know the context of a translated string, and i think that it’s best to see it in context in order to create best translations.

How to handle more than one locale?

The system simply will load one or another theme depending of the language. It also allows an easy handle or rtl and ltr languages, as well complex sentences structure in languages like chinese, russian, etc…

And i see a lot of advantages:

• Speed boost: less code to work with and cache boost
• Cleaning of a lot of template tags
• Deleting of a core function, with a reduction of complexity in all system.

Localization of content

Ok, now we have deleted MLS from core, but what if we want to have a multilanguage site?. We need an optional MLS module that handles ML options (themes to call, locales avaliables, etc…). Althought it can also be defined in a config xml file

But we’re in the same place… ok, with a speed bost and a complexity reduction, but now we also need a bit more. We need the option to translate content for some modules.

I’ve thought of various options, but i think the best one is to allow it though new MLS module, adding, for example, a structure like <xar:mlvar>$var</xar:mlvar>. It could be done thanks to DD.

Each time a mode is hooked to MLS module, it creates a DD subform object with the same structure of the item it’s hooked. The only need is that the original module has a lang var (like articles).

When system find <xar:mlvar>$var</xar:mlvar> it check current user language and module and DD items, and have various options:

1. If item have translation in current locale, show it.
2. If item have not translation in current locale, doesn’t show it.
3. If item have not translation in current locale, show it in an avaliable locale, following an order defined in MLS module.

… I have a lot of other ideas, but now i have a great headache and i’ll leave it for the second post…

Como saben Tenerife sufrió hace unos días una gran tormenta llamada Delta, con vientos que llegaron a pasar los 140 km/hora. La zona metropolitana se encuentra con cortes constantes de luz, problemas de telefonía (fija y móvil) y en breve cortes de agua al no funcionar con normalidad las depuradoras.

Por suerte la tormenta no causó muchas pérdidas humanas, que viendo las fotos es difícil de entender. Nuestra oficina está ubicada en pleno centro de Santa Cruz y se nota que las reparaciones que se hicieron hace unos meses a las cristaleras funcionaron porque no entró ni una gota de agua. Ahora bien, los últimos tres días los hemos dedicado a trabajo administrativo y a diseñar como en los viejos tiempos sobre folios, ya que nuestro equipo informático sólo servía para ocupar espacio.

Hoy el Gobierno Canario anuncia que se muestra pesimista y que las obras son muy complicadas, por lo que durante unos cuantos días no creo que exista normalidad en nuestra isla.

Esto lo escribo desde el ordenador de casa, donde por unas horas tendré luz, y quería compartir con ustedes lo que vivimos, que desde un punto de vista económico está siendo devastador para muchos de nuestros amigos. Cuando se normalice un poco la situación añadiré una foto al post, de un reportaje que hicimos en el Puerto de Santa Cruz de Tenerife.