El rediseño de gentoo.org, Parte 1: El renacimiento de un sitio

1.  Una multitud rebelde

Compañero desarrollador de software. ¿Puedo hacerle una pregunta?. ¿Por qué aunque a muchos de nosotros nos son íntimamente familiares las tecnologías Web como HTML, CGI, Perl, Python, tecnologías Java y XML en nuestro propios sitios Web -- los que están entregados a nuestros valiosos proyectos de desarrollo -- tienen pinta de haber sido generados por una multitud de chicos hiperactivos de 12 años?. ¿Por qué?. ¿Por qué sucede esto?

¿Podría ser porque la mayor parte del tiempo, hemos dejado que nuestro sitio Web se pudra mientras derrochamos nuestro precioso tiempo hackeando nuestros proyectos de software libre?. La respuesta, al menos en mi caso, es un "Sí" rotundo.

Cuando no estoy escribiendo artículos para IBM developerWorks o soy padre de nuevo, trabajo efervorecidamente en la siguiente revisión de Gentoo Linux, con mi equipo de expertos voluntarios. Y sí, Gentoo Linux tiene su propio sitio Web (mire en Recursos). A fecha de hoy (Marzo de 2001), nuestro sitio Web no es muy especial; esto es porque no empleamos mucho tiempo trabajando en él ya que normalmente estamos ocupados en mejorar el propio Gentoo Linux. Seguro, nuestro sitio tiene varios logos realmente bonitos que preparé rápidamente usando Xara X (mire en Recursos). Sin embargo, cuando se mira con atención, nuestro sitio deja mucho que desear. Quizás el suyo también. En este caso, tengo algo que decirle -- bienvenido al club.

2.  www.gentoo.org

En nuestro caso, el dilema en nuestro sitio Web existe porque nuestro proyecto ha continuado creciendo y nuestro sitio Web no. Ahora que Gentoo Linux se acerca a su revisión 1.0 (cuando esté disponible para no desarrolladores) y esta ganando popularidad, necesitamos empezar a mirar seriamente cómo nuestro sitio Web puede servir a sus usuarios. Aquí se muestra una captura de pantalla de www.gentoo.org:

Ilustración 2.1: El estado actual (Marzo de 2001) de los asuntos en www.gentoo.org

Como puede ver, tenemos los mínimos exigibles -- una descripción de Gentoo Linux, una lista de características, un registro de cambios (Changelog) diario (actualizado automáticamente gracias a Python), y un puñado de enlaces importantes (a los sitios de descarga, a las páginas de registro en nuestra lista de correo y a cvsWeb). Tenemos también enlaces a los tres recursos de documentación -- La Guía de Instalación y Desarrollo de Gentoo Linux, y la Guía de Solución de Problemas de NVIDIA de Christian Zander.

Sin embargo, aunque el sitio parece correcto, carecemos de un montón de cosas. La más obvia es la documentación -- nuestras guías de instalación y desarrollo necesitan mucho trabajo. Y entonces necesitaremos añadir una sección de FAQ, nuevos enlaces, nueva información de usuario... la lista es interminable.

Contenido vs. visualización

Y ahora llegamos a nuestro segundo problema. Ahora mismo, todo nuestro trabajo se realiza en HTML puro; yo mismo modifiqué a mano index.html hasta que se mostrara correctamente. Incluso peor, nuestra documentación Web está escrito en HTML puro. Esto no es bueno desde la perspectiva de un desarrollador porque nuestro contenido (que consiste en párrafos, secciones, capítulos) está enrevesado con un puñado de etiquetas HTML relacionadas con la presentación. Esto, desde luego, hace difícil cambiar tanto el contenido como el aspecto de nuestro sitio. Aunque este enfoque ha funcionado hasta hoy, está predestinado a causar problemas, ya que nuestro sitio continuará creciendo.

Claramente, necesitábamos usar mejores tecnologías detrás del escenario. En lugar de usar HTML directamente, necesitábamos comenzar a usar cosas como XML, XSLT y Python. El objetivo es automatizar tanto como sea posible para que podamos añadir y expandir nuestro sitio fácilmente. Si hacemos nuestro trabajo bien, incluso los cambios de mayor importancia en nuestro sitio, deberían de ser relativamente fáciles.

¡Una estrategia!

Estaba claro que teníamos mucho trabajo por delante. De hecho, había tanto por hacer que no sabía por donde empezar. Mientras estaba tratando de ordenarlo todo en mi cabeza, encontré por casualidad la columna de Laura Wonnacott's en InfoWorld "Site Savvy" (mire en Recursos). En ella, explica el concepto de diseño centrado en el usuario ("user-centric" design) -- cómo mejorar un sitio Web mientras se mantienen las necesidades de su público objetivo (en este caso los usuarios y desarrolladores de Gentoo Linux) en mente. Leer el artículo y echar un vistazo al enlace "Manual de Diseño Centrado en el Usuario" me ayudó a formular una estrategia -- un plan de acción -- para el rediseño:

1. Primero, defina claramente la meta oficial del sitio Web -- escribiéndolo. ¿Para qué esta allí?, y ¿qué se supone que tiene que hacer?
2. Identifique las diferentes categorías de usuarios que entran en su sitio -- su público objetivo. Ordénelos por prioridad: ¿Cuáles son los más importantes?
3. Ponga en marcha un sistema para recoger las aportaciones de su público objetivo, de modo que puedan hacerle saber lo que está bien y lo que está mal.
4. Evalúe estas aportaciones y úselas para determinar qué partes del sitio necesitan ser mejoradas o rediseñadas. Aborde las secciones de mayor prioridad en primer lugar.
5. Una vez seleccionada la parte del sitio a mejorar, ¡póngase a trabajar!. Durante la implementación, asegúrese de que el contenido y el diseño de la nueva sección atiende específicamente las necesidades de su público objetivo y corrige todas las deficiencias conocidas.
6. Cuando se ha completado el rediseño de la sección, añádalo a su sitio, incluso si tiene un aspecto que es marcadamente diferente de su sitio actual. De esta forma, sus usuarios pueden empezar a beneficiarse de la nueva sección rediseñada de forma inmediata. Si hay algún problema con el rediseño, tendrá que recoger comentarios de los usuarios rápidamente. Finalmente, realizando mejoras incrementales a su sitio (en lugar de modernizar el sitio completamente y desarrollando todo de una vez -- ¡sorpresa!) le ayudará a evitar que sus usuarios tengan la sensación de ser alienados por los (posiblemente dramáticos) cambios que ha realizado.
7. Después de completar el paso 6, salte al paso 4 y repita.

El enunciado de misión

Me hizo ilusión descubrir que teníamos el paso 3 resuelto. Habíamos recibido varias sugerencias por correo electrónico de los invitados del sitio y nuestra lista de correo de desarrollo también sirvió como forma de intercambiar sugerencias y comentarios. Sin embargo, nunca completé realmente los pasos 1 y 2. Aunque las respuestas pueden parecer obvias, encontré de gran ayuda sentarme y escribir nuestro enunciado de misión:

www.gentoo.org existe para ayudar a aquellos que usen y desarrollen Gentoo Linux aportando información relevante y actualizada acerca de Gentoo Linux y Linux en general, enfocando en aspectos relacionando con la instalación, el uso, la administración y el desarrollo de Gentoo Linux. Como el punto central de todos los asuntos Gentoo, el sitio debía ofrecer noticias importantes relevantes para los usuarios y desarrolladores de Gentoo Linux. Además de atender a los usuarios y desarrolladores de Gentoo Linux, www.gentoo.org tiene el propósito secundario de atender a las necesidades de los usuarios potenciales de Gentoo Linux, ofreciendo la información que necesitan para decidir si Gentoo Linux es apropiado para ellos.

El público objetivo

Hasta aquí bien. Ahora a por el paso 2 -- definiendo nuestro público objetivo:

www.gentoo.org tiene tres públicos objetivo -- los desarrolladores, los usuarios y los usuarios potenciales de Gentoo Linux. Aunque ningún grupo tiene absolutamente mayor prioridad que otro, actualmente las necesidades de los desarrolladores de Gentoo Linux son nuestra mayor prioridad, seguidos de los usuarios de Gentoo Linux y los usuarios potenciales. Esto es debido a que Gentoo Linux se encuentra actualmente en un estado de pre-revisión. Cuando Gentoo Linux alcance la versión 1.0, los usuarios de Gentoo Linux y los usuarios potenciales se convertirán también en prioritarios.

Comentarios y sugerencias

De acuerdo, ahora es el momento de evaluar las sugerencias y los comentarios que hemos recogido:

A lo largo de los últimos meses, hemos recibido un gran número de sugerencias de los visitantes del sitio Web. De manera aplastante, la gente esta solicitando mejor documentación -- tanto para desarrolladores como para usuarios. Varios desarrolladores han preguntado si podrían crear un lista de correo que fuera dedicada exclusivamente a describir los commits en CVS.

Como nota interesante, hemos recibido también un par de correos preguntando si Gentoo Linux es un producto comercial o libre. Creo que es porque en nuestro logo principal esta inscrito el nombre "Gentoo Technologies, Inc." (el nombre legal de nuestra corporación). La gente asume que tenemos un enfoque comercial. Modificando nuestro logo para que se lea "Gentoo Linux" y añadiendo un pequeño párrafo a la página principal explicando que somos un proyecto de software libre, podría ayudar.

La lista de mejoras

De acuerdo, ahora convirtamos estas sugerencias en una lista de posibles mejoras:

• Modernizando la página principal
  • Implementación: actualizar el logo y añadir la nota publicitaria de software libre
  • Objetivo: dejar bien claro que somos un proyecto de software libre
  • Público objetivo: usuarios potenciales
  • Dificultad: media
• Mejorar la documentación básica de usuario
  • Implementación: nuevo sistema XML/XSL, documentación prolija
  • Objetivo: hacer más fácil a los usuarios instalar Gentoo Linux
  • Público objetivo: usuarios nuevos
  • Dificultad: media
• Mejorar/crear documentación para el desarrollador
  • Implementación: nuevo sistema XML/XSL, guía CVS, guía de desarrollo, guía de Portage
  • Objetivo: ayudar a nuestros desarrolladores a hacer un mejor trabajo
  • Público objetivo: desarrolladores
  • Dificultad: alta
• Añadir una lista de correo CVS
  • Implementación: usar nuestro actual gestor de listas de correo mailman
  • Objetivo: informar mejor a nuestros desarrolladores
  • Público objetivo: desarrolladores
  • Dificultad: fácil

¡Una selección!

Dos cosas resaltaban en la lista por razones diferentes. La primera es la lista de correo CVS -- esta es trivial porque es muy fácil de implementar. A menudo, tiene sentido implementar los cambios más sencillos en primer lugar, de manera que los usuarios se puedan beneficiar cuanto antes.

La segunda gran cosa que salta a la vista de la lista es la necesidad de documentación para el desarrollador. Este es un proyecto a largo plazo que requiere mucho más trabajo. En mis conversaciones con otros desarrolladores parecía que todos estábamos de acuerdo que algún tipo de enfoque XML/XSL es la solución correcta.

El prototipo XML/XSL

Para ayudar a que el proceso comenzara, desarrollé una sintaxis prototipo de XML para ser usada en toda nuestra documentación en línea. Usando esta sintaxis XML (llamada "guía"), nuestra documentación estará claramente organizada en párrafos, secciones y capítulos (usando etiquetas XML como <section>, <chapter>, etc.) mientras se mantiene libre de cualquier etiqueta relacionada con la visualización. Para crear el HTML a mostrar en nuestro sitio, creé algunas transformadas XSL prototipo. Usando un procesador XSLT como Sablotron, nuestros ficheros guía XML pueden ser convertidos en HTML de la forma que sigue:

devguide.xml + guide.xsl ---procesador XSLT---> devguide.html

Lo grande de este enfoque XML/XSLT es que separa nuestro contenido en bruto (XML) de la información relacionada con la visualización contenida en el fichero guide.xsl (XSLT). Si necesitáramos actualizar el aspecto de nuestras páginas Web, simplemente modificaríamos el fichero guide.xsl y ejecutaríamos todo nuestro XML con el procesador XSLT (Sablotron), creando páginas HTML actualizadas. O, si necesitamos añadir nuevos capítulos a la guía de desarrollo, podemos modificar devguide.xml. Una vez lo hayamos hecho, corremos el XML con Sablotron, el cual genera un fichero completamente formateado devguide.html, con algunos capítulos añadidos. Piense en XML como el contenido y XSLT como las macros relacionadas con el formateo y la visualización.

Aunque nuestro equipo completo está convencido de que XML/XSLT es la forma de hacer las cosas, aún no nos hemos puesto de acuerdo acerca de una sintaxis XML oficial. Achim, nuestro líder de desarrollo, sugirió que usáramos docbook en lugar de desarrollar nuestra propia sintaxis XML. Sin embargo, el formato prototipo de guía XML ha ayudado a comenzar el proceso de toma de decisiones. Ya que nosotros, los desarrolladores, vamos a ser los que usemos el XML/XSL a diario, es importante elegir una solución con la que estemos cómodos y cubra todas nuestras necesidades. En mi próximo artículo debería tener un sistema de documentación XML/XSL que mostrarle.

Demostración tecnológica: pytext

En mayor parte, nuestro sitio Web no está usando ninguna tecnología nueva o de última moda que merezca la pena nombrar. Sin embargo, hay una notable excepción -- nuestro pequeño intérprete de Python incrustado: pytext.

Como muchos, soy un grandísimo fan de Python y lo prefiero bastante a otros lenguajes interpretados, por eso cuando llegó el momento de añadir algún contenido dinámico a nuestro sitio Web, naturalmente quería usar Python. Y, como probablemente sabe, cuando se codifica contenido HTML dinámico, es normalmente más conveniente incrustar los comandos del lenguaje dentro del HTML, en lugar de hacerlo al contrario. Por eso la necesidad de un intérprete de Python incrustado para tomar un documento como éste:

<p>
Sí, claro; tengo algunas preguntas:<br>
<!--code
names=["bob","jimmy","ralph"]
items=["calcetín","almuerzo","acordeón"]
for x in items:
for y in names:
print "¿Alguien ha visto el ",x+"de",y+"?<br>"
-->
Ves, te lo dije.

....Y transformarlo en esto:

<p>
Si claro; tengo algunas preguntas más:<br>
¿Alguien ha visto el calcetín de bob?<br>
¿Alguien ha visto el calcetín de jimmy?<br>
¿Alguien ha visto el calcetín de ralph?<br>
¿Alguien ha visto el almuerzo de bob?<br>
¿Alguien ha visto el almuerzo de jimmy?<br>
¿Alguien ha visto el almuerzo de ralph?<br>
¿Alguien ha visto el acordeón de bob?<br>
¿Alguien ha visto el acordeón de jimmy?<br>
¿Alguien ha visto el acordeón de ralph?<br>
Ves, te lo dije.

Aquí está el código fuente para pytext:

#!/usr/bin/env python

# pytext 2.1
# Copyright 1999-2001 Daniel Robbins
# Distributed under the GPL

import sys

def runfile(myarg):
   "interprets a text file with embedded elements"
   mylocals={}
   try:
      a=open(myarg,'r')
   except IOError:
      sys.stderr.write("!!! Error opening "+myarg+"!\n")
      return
   mylines=a.readlines()
   a.close()
   pos=0
   while pos<len(mylines):
      if mylines[pos][0:8]=="<!--code":
  mycode=""
  pos=pos+1
  while (pos<len(mylines)) and (mylines[pos][0:3]!="-->"):
       mycode=mycode+mylines[pos]
       pos=pos+1
  exec(mycode,globals(),mylocals)
       else:
  sys.stdout.write(mylines[pos])
       pos=pos+1

if len(sys.argv)>1:
   for x in sys.argv[1:]:
       runfile(x)
   sys.exit(0)
else:
   sys.stderr.write
     ("pytext 2.1 -- Copyright 1999-2001 Daniel Robbins. ")
   sys.stderr.write
     ("Distributed under the\nGNU Public License\n\n")
   sys.stderr.write
     ("Usage: "+sys.argv[0]+" file0 [file1]...\n")
   sys.exit(1)

Cómo funciona pytext

Aquí se muestra cómo trabaja. Escanea cada línea de entrada, la mayor parte del tiempo cada línea de entrada es simplemente enviada a stdout. Sin embargo, si pytext encuentra una línea que comienza por <!--code entonces el contenido de cada línea hasta la primera línea que comienza por --> son añadidas a una cadena llamada mycode. Pytext entonces ejecuta la cadena mycode usando la función built-in exec(), creando efectivamente un intérprete de Python.

Hay algo realmente bonito en esta implementación en particular -- llamamos a exec() de una forma en la que todas las modificaciones a los espacios de nombres tanto globales como locales son guardados. Esto hace posible importar un módulo o definir una variable en un bloque incrustado, y entonces acceder a este objeto creado previamente en un bloque posterior, como este ejemplo claramente demuestra:

<!--code
import os
foo=23
-->

Hola

<!--code
print foo
if os.path.exists("/tmp/mytmpfile"):
print "Existe"
else:
print "No lo veo"
-->

Útil ¿no?, pytext es una excelente demostración de la potencia de Python y es una herramienta extremadamente útil para los fans de Python. En nuestro sitio actual, llamamos a python desde una tarea cron, usándolo periódicamente para generar el código HTML para nuestra página principal del registro de cambios (Changelog):

pytext index.ehtml > index.html

Eso es todo por ahora; ¡le veré la próxima ocasión en la que echaremos un vistazo a la primera etapa del rediseño de www.gentoo.org!

3.  Recursos

• Lea los otros artículos de esta serie de developerWorks sobre el rediseño del sitio Web www.gentoo.org usando tecnologías como XML, XSLT y Python:
  • En la Parte 2, Daniel nos muestra el nuevo sistema de documentación y pone en marcha una lista de correo diaria CVS-log (Mayo 2001).
  • En la Parte 3, crea un nuevo aspecto para el sitio (Julio 2001).
  • En la Parte 4, Daniel completa la conversión a XML/XSLT, corrige un montón de errores para el navegador Netscape 4.x, y añade al sitio un registro de cambios XML (Changelog) autogenerado (Agosto 2001).
• Si no ha comenzado a usar Python aún, simplemente se está perjudicando a sí mismo. Encuéntrelo en http://www.python.org.
• La columna Site Savvy de Laura Wonnacotr aparece regularmente en InfoWorld.com.
• Eche un vistazo a Xara.com, el lugar de Xara X -- un excelente paquete de dibujo vectorial para Windows. Sin apenas grandes pretensiones y una velocidad impresionante, obtiene mi recomendación personal.
• Aprenda más acerca de XSLT en http://www.xslt.com
• Cuando despierte, pruebe Sablotron, un procesador XSLT rápido disponible en Gingerall