virtualizada: blog de carmel hassan - blog de carmel hassan (web for human beings: informática, drupal, ingeniería web)

[libro] Cómo escribir para la web

karmel — Tue, 30 Dec 2008 08:55:12 +0000

"Cómo escribir para la Web" es el títutulo del libro publicado por el Centro Knight para el Periodismo en las Américas de la Universidad de Texas, en Austin, y escrito por el periodista colombiano Guillermo Franco.

Este libro, escrito en castellano y disponible para su descarga en PDF de forma gratuita, es un recurso muy útil que utiliza los últimos estudios de EyeTracking y artículos de Nielsen como base argumental de las técnicas periodísticas y literarias para construir artículos y exposiciones de contenidos de calidad.

Escrito por un periodista y dirigido a este mismo tipo de profesionales a través del llamado Periodismo 2.0, nos recuerda todos los demás los aspectos del contenido que no debemos dejar pasar:

Los usuarios leen sólo lo que les interesa porque les llama la atención, no todo es lectura superficial.
Los párrafos cortos y concisos, el lenguaje objetivo, la estética, el uso de negrita, los intertítulos ayudan a explorar y encontrar la información.
Usar la pirámide invertida como método de narración.
Evitar la necesidad de lectura lineal de la información
Usar palabras clave dentro del texto facilita el posicionamiento en buscadores, así como las tags y los titulares relacionados.

Finalmente, incluye un capítulo dedicado a los microblogs muy interesante del que he podido reafirmarme en mi decisión de renuncia al usar Twitter únicamente como amplificador de la información que transmito principalmente por mi blog. Curiosamente también menciona cómo Facebook tiende a convertirse en un Twitter por la forma de usar el "estado".

Virtualizada cumple dos años

karmel — Tue, 23 Dec 2008 19:02:46 +0000

Sé que no es mucho tiempo para esto de un blog, casi nada. Desde que en 2004 me aficionara a exhibir mis pensamientos en público (en Aficiona2), pasara por exhibir mis poemas (en "Con el tiempo justo" y La coctelera), exhibir mis hiperbreves (en Aficiona2 (beta)), incluso a comentar en otros blogs! (me doy pereza), vengo manteniendo actualizado este blog sin mucho éxito aunque con gratitud.

Este blog existe desde el Diciembre de 2006 y siempre he procurado mezclar ideas con un tono entre lo personal y lo profesional, lo técnico y lo humano, lo actual y lo desfasado.

Y de esta manera celebro el comienzo del tercer año, sin crisis pero sin pausa. Felices fiestas y buena entrada de año 2009.

Por qué no elegir entre Drupal y RoR

karmel — Mon, 22 Dec 2008 20:05:50 +0000

En contadas ocasiones nos hemos visto frente a la dura tarea de decidir qué herramienta es la más apropiada para hacer determinada cosa. Normalmente nos paramos a analizar nuestras necesidades y rápidamente nos vamos a conocer las características de estas herramientas, aunque, muchas veces simplemente queremos buscar la respuesta a la pregunta del millón de dólares: "cuál es la mejor" obviando el "para qué".

En cualquiera de los casos y por lo que conozco a Drupal y RoR (Ruby on Rails), he llegado a la conclusión de que compararlas en la búsqueda de la fuente de la eterna... agilidad, es imposible. Estas son mis conclusiones:

Arquitectura

Drupal es un CMS y Rails un framework, no quiere decir que no se pueda programar un gestor de contenidos sobre Rails ni que Drupal no sirva como entorno de desarrollo de aplicaciones.

Las arquitecturas de ambas herramientas son diferentes, el modelo vista controlador (MVC) que implementa Rails permite la separación del manejo, control y visualización de los datos nada tiene que ver con la lógica de drupal, en cierto modo en Drupal sí existe una capa para el modelo (nodos), el controlador (los hooks) y la vista (sistema de plantillas).

El MVC es estándar y conocido por los programadores y lo que usa Drupal es propio, para comparar necesitaríamos irnos a términos de eficiencia en la generación de datos y respuesta a eventos, por ejemplo.

Metodología de programación

Ruby es un leguaje orientado a Objetos y, aunque PHP también lo es, Drupal no usa clases pero sí mantiene los paradigmas de la orientación a objetos. Qué te hace más feliz cuándo programas?

En ambos se pueden desarrollar test unitarios y en ambos existen guías de estilo para programadores y API's.

Desarrollo ágil

Ruby es ágil en el desarrollo de aplicaciones, Drupal es ágil en el desarrollo de sitios webs.

Quizá Ruby está pensado para programadores que, a pesar de haber tenido que incorporar nuevas metodologías de desarrollo más allá del proceso iterativo incremental del desarrollo software, han sabido sacar partido a la potencia del lenguaje para generar poco código, legible y no redundante.

Drupal, en cambio, es ágil en la puesta en marcha de portales por casi cualquier usuario. Esto dificulta cualquier metodología clásica y moderna de desarrollo y volvemos a la búsqueda de un método propio.

Ruby vs PHP, Drupal vs Rails

Las comparaciones se hacen más difíciles si nos vamos a la base de las herramientas, si separamos el leguaje del entorno y lo comparamos entre sí.

"Ruby mola" es el lema de los evangelistas, en mi opinión Rails es lo que mola. Ruby on Rails vs PHP, también es una comparación sin sentido.

Drupal es orientado al cliente y Rails al programador, Drupal requiere mucha configuración y Rails casi nada. Drupal no es tan flexible, tiene un coste mayor para aplicaciones, pero Rails no se extiende con la potencia con la que los módulos lo hacen, a través de la ingeneniería de hooks y themes engines.

Comunidades

Este es otro punto de la discordia, mientras que la comunidad de usuarios de Drupal crece por su uso. Rails crece por su promoción. Esto no quiere decir que una cosa sea mejor que otra sino que la comunidad a la que va dirigida la herramienta es totalmente diferente, al menos de momento, por lo que comparar este punto también es costoso.

Según tengo entendido, está dentro de los propósitos de Drupal aprender de la capacidad de márketing de Rails, desconozco los propósitos de Rails para en este punto aunque el planteamiento es muy bueno: felicidad para el programador.

Redes sociales creativas

karmel — Fri, 19 Dec 2008 14:45:08 +0000

Últimamente me vengo quejando mucho de Facebook (y eso que no pertenezco a Prisa) y una de mis razones es por la inútilidad per se de la aplicación. En realidad, muchas redes sociales se construyen en base a esta libertad para usarlas como el usuario quiera, es la gracia que tienen.

En cuanto a las críticas que de ellas se hacen se asemeja al refranero español, que siempre encuentras dos buenos refranes totalmente opuestos: o son exhibicionistas o es precioso compartir, son innovadores en cuanto al modelo de negocio o pierden su público rápidamente.

Tumblr nació como otra red social más pero mejorando Twitter, que empeoraba el blogging llamándolo mircoblogging, que se llamaba democrático o bien populista (según el crítico). Tubmlr se planteó para que fuera muy sencillo de usar aunque es difícil de intuir a priori: ¿qué es el reblog? un comentario? un trackback? un shout? muro-a-muro? @you?

Lo que me ha llamado la atención sin embargo es que Tumblr se ajusta exactamente a un ejercicio de literatura creativa muy interesante: la historia encadenada.

Es como una vuelta al hipertexto combinado con un inveta / sigue tu propia aventura: el reblog es una descentralización total de la conversación, sin perder el rastro de los orígenes de la información.

Yo he empezado esta historia, es la historia más larga peor contada, no sé si funcionará o no. Podrán ser muchas historias o ninguna, o solo la tuya, la tuya y la mía, de mis amigos o la de cualquiera, incluso la de IBM si decide cambiar su modelo de negocio.

Content Strategy: el contenido usable

karmel — Wed, 17 Dec 2008 16:53:24 +0000

Content Strategy es una disciplina emergente que, según la autora del artículo "Content Strategy: The Philosophy of Data" es al copywriting lo que la arquitectura de la información es al diseño.

Pero es mucho más. Partiendo de la filosofía de que todo en la web es contenido, la estrategía del contenido (traducción propia) abarcaría disciplinas para definir: palabras clave y mensajes, temas recomendados, metadata, SEO...

Ya en A list Apart encontramos, además, la discusión de en qué momento introducimos esta estrategia en el proceso de desarrollo, quién se hace responsable del contenido: ¿el cliente? ¿los usuarios? ¿los diseñadores?

No es sencillo tomar una determinación, mezclarla (más bien integrarla) con conceptos como el desarrollo ágil, pero estoy convencida de que es necesario ser consciente de hasta dónde puede afectar y cómo podemos mejorar o, al menos no estropear, lo que tratamos de hacer de forma tan preocupada a través del diseño web, el diseño centrado en el usuario, la programación estándar y otras tantas disciplinas.

Por eso me gustaría proponer una forma de incluir la estrategia del contenido en las diversas fases de desarrollo. Nota: estas no son las fases de un desarrollo web, sólo son las fases en las que me gustaría destacar la inclusión de la disciplina.

Paso 1: Análisis de palabras

Una buena forma de comenzar un proyecto es analizando las expresiones, verbos y sustantivos usados por el cliente para describir su idea de web o explicar sus necesidades. Es la llamada técnica Abbott.

Muchas veces, esta descripción viene en formato texto, por lo que es aún más fácil identificar estas palabras clave que, además, podrán convertirse en muchos casos en objeto de clasificación para la definición de la arquitectura del sitio.

Paso 2: Análisis de audiencias

Durante el proceso de definición de audiencias y personas (arquetipo) podemos añadir un nuevo atributo, que se caracterice por el lenguuaje coloquial que podría manejar ese arquetipo de persona.

Quizá, es muy pronto para tenerlo en cuenta pero, al igual que se hace separando los casos de uso según las tareas que en él intervengan, así debería hacere según la audiencia para adaptar el lenguaje intercambiado en la comunicación al arquitepo implicado.

Sergio Ortega lo explicaba muy bien (http://www.nosolousabilidad.com/articulos/modelo_comunicacion.htm) y rescato un titular ilustrativo: ¿qué te voy a contar? ¿qué me vas a entender?

Paso 3: Card Sorting

El Card Sorting es una técnica de agrupación de palabras según su relación temática que permite conocer cómo los usuarios agrupan y asocian términos.

Lo que buscamos es averiguar el modelo mental de los usuarios para adaptar la web a su audiencia.

En este caso, jugaría una segunda vuelta en esta técnica: una vez hechas las agrupaciones, otorgar una definición a cada una de las clasificaciones tal como los participantes lo han entendido.

De aquí podríamos analizar la persona en la que el usuarios expresa la definición, si usa sinónimos o incluye alguno de los términos del grupo, el tiempo gramatical, etcétera, con la intención confeccionar un lenguaje aproximativo entre los conceptos y los usuarios.

Paso 4: Prototipado

El prototipado nos servirá para dar la primera propuesta en la construcción del sitio y con él al lenguaje de la interfaz, de los datos y de los avisos del sistema.

Podemos incluir como nuevas pantallas o elementos del wireframe en los que se empiece a vislumbrar los textos de enlaces, menús, botones, títulos, subtítulos, etcétera.

Quizá en este punto pudiera resultar prematuro incluir "contenido", es posible que comience a construirse la sensación completa de la web cuando la idea del prototipo no es esa. Me surgen dudas al respecto, no obstante podríamos dividir este paso en 2, para hacer notar la diferencia:

Prototipo no funcional (wireframe)
Prototipo de contenido (contentframe)

Paso 5: Programación, Maquetación y Diseño (no más lorem ipsum)

Agrupo estas áreas porque en cualquier momento y desde cualquiera de los participantes en el desarrollo de la web puede aportarse algo para una estrategía del contenido, sin que esta sea excluyente y partiendo siempre desde lo conseguido en pasos anteriores.

De hecho ellos deben ser los implementadores de esta estrategia con una labor aún más importante: si durante el proceso de desarrollo contamos con contenido real (porque el cliente se ha implicado suficiente con el proyecto) sólo los desarrolladores pueden sumar todas las decisiones del análisis al resultado final.

Coincidiendo con Jesús Encinar no termina de convencerme el uso de textos Lorem Ipsum, creo que en exceso queda fuera de los objetivos de esta estrategia, casi por definición.

Conclusiones

A medida que van surgiendo nuevas disciplinas creo que no debe dejarse de lado la idea de encontrar metodologías que ayuden a ponerlas en práctica. Este pequeño artículo he intentado abarcar dentro del proceso de ingeniería web cómo introducir estas técnicas que ayudan a obetener resultados con mayor calidad. Por supuesto, cualquier referencia o comentario son bienvenidos.

Nota: mientras escribía este artículo, A list Apart ha publicado un segundo artículo que nos da más pistas sobre Content Strategy muy interesante.

Actualizando el blog

karmel — Sun, 14 Dec 2008 21:17:42 +0000

Durante estos días estoy actualizando de la versión 5.14 a la 6.8, por lo que el blog puede sufrir algunos cambios hasta que vuelva a dejarlo todo en su sitio, entre otras cosas el aspecto, que por el momento he tratado de dejarlo legible al máximo.

Disculpad las molestias, nada de qué preocuparse desde los lectores RSS.

Páginas de acceso denegado y no encontrado

karmel — Wed, 10 Dec 2008 17:17:22 +0000

Hace unos días nos leíamos un artículo en A List Apart muy interesante, reflexionando acerca de cómo mejorar el error 404 en un servidor. A grandes rasgos, proporcionaba un script en Perl para averiguar por qué se había producido el error 404 y así ofrecer una informacion un poquito más útil a los usuarios que se encontraban con esta página.

Drupal no es tan versátil en este caso, pero mejorar la usabilidad de los sitios web es un poco más fácil gracias a que permite la configuración de las páginas de Acceso Denegado y Página No Encontrada.

Acceso denegado

Es un error que transmite Drupal desde el servidor, con código 403, cuando se está intentando hacer una petición a una página para la que no se tiene acceso.

Página no encontrada

Este mensaje es enviado también por el servidor web, con código 404, que informa de que la dirección http que se ha introducido no existe.

En el caso de Drupal, ambas páginas pueden configurarse para que sean un poco más amigables, ¿cómo?

1º Creamos dos nuevas páginas (node/add/page), un texto que puede servir es:

No hemos encontrado la página

La dirección que nos indica no corresponde con ninguna página en esta web. Asegúrese de que la URL está bien escrita o use nuestro buscador.

Atentamente, El Equipo del sitio.

No puede acceder a esta sección

Lo sentimos, pero no podemos darle acceso a esta sección. Si es usted usuario de nuestra web puede intentarlo de nuevo autentificándose. Si el problema persiste y necesita del acceso, consulte con un administrador de la web.

Atentamente, El Equipo del sitio.

2º Desde la dirección (relativa) admin/settings/error-reporting de nuestro sitio podremos indicar los nodos correspondientes

Los mensajes son sólo una sugerencia, se trata siempre de informar y dar alguna opción al usuario, ya que ha llegado a la web, aunque sea a través de un enlace roto que no pierda la esperanza. En el caso de acceso denegado es incluso más importante, cuántas veces habremos olvidado conceder los permisos suficientes a un usuario. Tampoco viene mal advertir que efectivamente, existen áreas que son restringidas sin que la privacidad resulte excluyente.

Al hilo del artículo, en Drupal falta aún dar un poquito más de información a los desarrolladores, para conocer las causas exactas del error y tratar de evitarlo, aunque para eso aún podemos acudir a espiar los registros (logs) de las diversas herramientas.

Otra forma de maquetar nodos: Views + Panels 2

karmel — Tue, 09 Dec 2008 20:18:15 +0000

Desde que intenté sobreescribir un perfil de usuario creando una vista y enviando argumentos (no lo intentéis, no funciona!) me he topado siempre con el mismo problema: el de poder elegir libremente la manera en que se muestran los datos en un nodo.

Entonces se publicó Panels 2 , la segunda versión de un módulo que en principio sólo servía para crear un nuevo layout dentro de la zona de contenido principal. Los panels permitían entonces mostrar bloques o páginas creadas con vistas y enviar argumentos hacia la página (si existía) de la vista completa.

Esto, suponía ya de por sí una revolución, ya que facilitaba en cierto modo a los no maquetadores, crear de una forma ágil nuevas distribuciones y además más complejas con la ayuda de las vistas.

Ahora, Panels 2 le da una vuelta de tuerca a todo esto y permite redefinir páginas que ya existen como las de tipo node/<id> o user/<id>/edit, por ejemplo.

¿Qué nos permite esto?

Recolocar los elementos (como hasta ahora) y definir sobre ellos permisos de visualización, órdenes y condiciones...y todo eso que hacen las vistas.
No tocar el código, ni el del template ni el de contemplate.
Decidir cómo debe mostrarse un nodo al editarlo, visualizarlo y crearlo (sea del tipo que sea)

Todas estas segundas versiones, en principio complejas para la gente que nos revolucionamos cuando salió el proyecto Flexinode, siguen una tendencia marcada por las versiones 6 y 7 de Drupal, la de mejorar la usabilidad en la administración y con ella potenciar las posibilidades.

Reflexión personal

Aveces me pregunto si el hecho de intentar hacer las cosas bien, usables, inteligibles, simples, eficaces... no es precisamente lo que capacita a las herramientas para que por fin sean útiles.

Quizá haya ignorado durante mucho tiempo que ésto se podía hacer ya con algún truco de experto y con las anteriores versiones, pero ahora desde luego me queda claro que es posible.

En cuanto pruebe la segunda versión del Views seguro que descubro alguna nueva maravilla... o quizá no

De baja en Facebook y muy próximamente en Twitter

karmel — Wed, 03 Dec 2008 17:17:47 +0000

Tras haber esperado meses a que alguien me invitara a entrar en Twenti he decidido darme de baja en Facebook. Se ve que estoy en un middle-age duro.

Pueso eso, facebook es a las redes sociales lo que linux a las GUI.

El tiempo que gane lo dedicaré a ... darme de baja del resto de cosas sin sentido para poder dedicarme hacer algo útil.

Actualización: de alta en lastfm.es Twitter no me deja darme de baja.

Hablarle a los usuarios

karmel — Mon, 01 Dec 2008 19:50:43 +0000

Los lenguajes verbales en forma de textos que sirven para comunicar el sistema web con el usuario final, en mi opinión, conforman un nuevo idioma para cada nuevo sitio.

No se trata sólo de informar a un usuario de que el sistema ha generado esta u otra respuesta ante un evento, por ejemplo una búsqueda sin resultados, sino de comunicar lo que está ocurriendo, incluso, de ofrecerle alternativas que no le hagan sentirse frustado.

Mi teoría sacada de la manga es que a los usuarios hay que hablarles. Es cierto que no quieren pensar, el lenguaje siempre debe ser claro y conciso, pero tampoco quieren ser tratados como una máquina, con una respuesta automática e impersonal.

Es importante no olvidarse de esto ya que, si la web sólo informa y no comunica es porque hay una intención clara de no hacerlo y seremos nosotros los que, como desarrolladores o responsables de la web no queremos hacerlo.

Se trata, una vez más, de reforzar la confianza de los usuarios para que vean que no hay un ente vacío detrás de un comercio electrónico/portal corporativo/web personal/... Obviamente no somos nosotros los que hacemos el trabajo de responder a los eventos, pero sí nos convertimos en parte de la interfaz al poner nuestras mejores prácticas en la elaboración de desarrollos, contenidos, diseño, arquitecturas, etc.

Mi premisa a la hora de plantear un nuevo idioma para comunicarme con los usuarios es: más comunicación es más información y, siempre es fundamental extender el mensaje que propone el diseño.