CommonCraft se ha tomado la molestia de preparar un ilustrativo video acerca del uso de RSS en dos simples pasos. Muy Interesante, pero como dice el vídeo, «es aditivo, así que ¡tengan cuidado!». [guiño]
Vía Usolab.
Hoy leo un artículo de Ricardo Gopar acerca de la importancia de tener presencia en Internet, del que me gusta especialmente lo siguiente:
Quienes desean estar en la Red empresarialmente, permítanme aconsejarles por enésima vez, hacer las cosas bien, es decir, apostar por una definición previa del proyecto, una planificación, y un posterior desarrollo vigilado, medido y que responda a nuestras premisas iniciales. Y una vez lanzado el proyecto a Internet, planificación indefinida y seguimiento.
Lo que me recuerda que quería mostrarles algo de información acerca del proceso de desarrollo que seguimos en Clevernet (en inglés), basado en FLiP, del que todavía tengo que hablar.
Esta es una anotación publicada en mi antiguo blog sobre accesibilidad, usabilidad y estándares, TresOnce, el 2 de octubre de 2005. También puedes ver el texto original.
He visto por ahí que el uso de Javascript en las páginas web hechas en Canarias está bastante extendido. Al contrario de lo que sucede con flash (el cual requiere ciertos conocimientos y una familiarización previa con su entorno de trabajo), Javascript ofrece una buena relación potencia-sencillez, lo que permite a la mayoría crear pequeños scripts que den un toque a su web. En caso de que no seamos capaces de crear nuestro propio código, siempre podemos echar mano de websites como Hotscripts.
Pero no es oro todo lo que reluce. Muchas veces el intento del diseñador por darle un estilo sofisticado a la web hace que resulte un poco difícil de interpretar por el usuario medio.
Casos como estos son los de Menús Emergentes, los cuales aparentemente son estáticos, pero al pasar el cursor del ratón por encima despliegan una serie de opciones adicionales.
Haciendo esto corremos el riesgo de desorientar al visitante, ya que un usuario novel no tiene ni la más remota idea acerca de ese posible comportamiento, quizás hasta se vaya de la página por no encontrar lo que busca con un simple golpe de vista. En otros casos puede hasta verse abrumado por la cantidad de elementos que se muestran de golpe.
Por esto, lo recomendable es huir en la medida que sea posible de este tipo de menú. Si tienes que hacerlos, que sean ligeros (más de 6 elementos resultan demasiado para el usuario), coloca en los elementos del menú sólo aquellas categorías que sean importantes, y si el número de categorías es elevado, mejor plantéate una estructura de directorio, tal como el de Google.
Para finalizar, mucho ojo siempre que se utilice Javascript, ya que aquellos usuarios que no tengan activada la interpretación de este código necesitarán de alguna alternativa para no perderse nada. Lo mismo ocurre con aquellos usuarios que utilicen navegadores antiguos que no soporten Javascript.
Hace ya bastante tiempo que hice mi primera anotación acerca de Fusebox. Espero que no hayan perdido el hilo, si es que alguna vez lo siguieron. Para entender la filosofía de Fusebox, es imprescindible conocer sus componentes. Así que vamos con un poco de teoría.
Una fuseaction es un manejador de evento (event handler), normalmente para un método público. Cuando un circuito captura una petición para realizar una acción, recibe dicha petición en forma de fuseaction. Habrá una fuseaction por cada petición que el usuario hace a la aplicación.
Un circuit (circuito) es un fichero que agrupa una serie de fuseaction relacionadas entre si. Toda aplicación Fusebox está compuesta de uno o múltiples circuitos.
Un fuse o fusible es un fichero de código individual. Los fusibles son el bloque más básico en una aplicación Fusebox. Cuando se realiza una petición, se ejecutará el código contenido en los fuses englobados en la fuseaction solicitada. El ámbito de los fuses es siempre privado.
XFA es el acrónimo de eXit FuseAction (algo así como fuseaction de salida). Se trata de una idea muy útil, ya que en lugar de trabajar sobre una fuseaction, puede utilizarse una variable XFA. Las variables XFA son acciones predefinidas en el fichero fbx_switch (fusebox.xml en Fusebox 4 y posteriores). Usando una variable para definir una fuseaction, el código se vuelve más reutilizable. También, proporciona la posibilidad de cambiar, en tiempo de ejecución, lo que hará una fuseaction dada.
Los Fusedocs son una serie de comentarios estructurados utilizados para describir un fichero fuse, los valores que recibe, los valores que produce y otro tipo de detalles. Los Fusedocs no son imprescindibles, pero sí son una parte de FLiP. Tiene sentido que sean escritos antes de que el contenido de su fusible sea desarrollado, ya que describir y estructurar de antemano la aplicación con ellos, el código de la misma será más fácil de comprender y a la vez más estable. Los Fusedocs son también muy útiles a la hora de mantener el código. Originalmente, los Fusedocs eran simples comentarios en ColdFusion. Pero con Fusedoc 2, pasaron a escribirse en XML, lo que permitió la posibilidad de interpretar y usar la información contenida en ellos.
Próximamente, FLiP.
A través de un hilo en Cadius se generó durante esta semana el debate acerca de la ubicación de los menús de navegación (izquierda/derecha), «resucitando» una anotación de un blog del gremio. Más tarde, José Ramón Quevedo posteaba sobre la librería de patrones de diseño en Flickr propiedad de Christopher Messina.
¿A qué viene todo esto? Pues a que me recordó una conversación en el trabajo acerca de un proyecto. El debate iba acerca de la colocación apropiada del enlace para salir de una aplicación web (Log Out). Mi opinión era que dicho enlace debe ir colocado en la esquina superior derecha de la página, lo cual considero un patrón a seguir. Dando un vistazo rápido a un par de estas aplicaciones y los resultados son:
Yo diría que esto es un estándar de facto, ¿o no? [sonrisa]
