Método para el desarrollo de sitios en la Web

Por Eduardo Mercovich (edumerco@gaiasur.com.ar)

URL de este doc: http://planeta.gaiasur.com.ar/seminarios/metodo-websites.html

Tabla de contenidos

  1. ¿Método? ¿Qué método?
    1. Introducción
    2. Las razones
    3. ¿Qué necesito para utilizar el Método?
      1. Armar los Equipos
      2. Aprender los pasos del Método
      3. Evaluar en cada etapa
      4. Ser honesto
  2. El Método
    1. ¿En qué consiste el Método?
    2. Las Etapas
      1. Anteproyecto
      2. Diseño
      3. Implementación
      4. Publicación y medición
      5. Evaluación
  3. Una vez que terminamos con el desarrollo inicial
    1. ¿Y ahora?
  4. Ejemplo práctico del método: La Asociación de Amigos del Tranvía

¿Método? ¿Qué método?

Este documento presenta un método para desarrollar Web sites, que surge de nuestra experiencia y nuestros resultados. Pretendemos con esto ayudar a quienes forman parte de un grupo de desarrollo o tienen a cargo el proyecto de un Web site.

Para hacer la explicación algo más amena, en vez de desarrollar el método en profundidad sólo en forma teórica, redujimos al mínimo la parte conceptual y presentamos en detalle un ejemplo, de manera de cubrir un posible proyecto en forma completa de principio a fin.

Si bien este ejemplo no es real, tampoco se trata de un modelo totalmente ideal, ya que está armado con partes y experiencias de proyectos reales.

Por lo tanto, aunque puede leerse en cualquier orden, recomendamos avanzar sobre los conceptos y el ejemplo en forma paralela.

Introducción

Además de la sorpresa que suscita la mera existencia de un método como el que presentamos, muchos se preguntarán: "Si yo contrato a un grupo para que me haga el sitio, ¿por qué molestarme en aprender cómo se hace un sitio?"

La respuesta es: "Porque para poder elegir, hay que saber". Si alguien pretende venderle un auto y al levantar el capot, usted ve que no tiene motor, seguramente no lo compraría.

Sin embargo, muchas empresas u organizaciones compran proyectos de Web sites que, por ejemplo, nunca presentan evaluaciones para ver si sirven para algo, o si funcionan como se supone que deberían funcionar. O reciben presupuestos por un sitio que no se sabe aún cómo va a ser. En ese caso, ¿cómo se pudieron estimar plazos y costos?

No se puede exigir sobre lo que no se conoce, ni se sabe cuánto vale un trabajo del que no se tiene idea en qué consiste. Para elegir y evaluar el servicio contratado (sea a personal interno o externo) hay que saber previamente qué debe haber en una propuesta, qué cosas se deben exigir, qué es fácil y qué es difícil.

El método aquí presentado –que no sólo sirve para sitios sino que, con pequeñas variaciones, es útil para aplicaciones hipermediales en general– ya ha sido probado y ha demostrado su utilidad muchísimas veces, además de haber sido refinado a lo largo del tiempo.

Seguramente existen otros métodos. No los conocemos ni los hemos probado como a éste. Por lo tanto, nos remitimos a nuestra humilde experiencia.

La idea general del Método se basa en procedimientos de ingeniería con varios agregados que contemplan los requerimientos de todo el aspecto creativo-artístico. Además, es iterativo, es decir que aplica repetidas veces.

El Método nunca recorre el mismo camino porque no hay dos proyectos iguales, pero siempre sigue la misma secuencia de etapas.

El concepto básico es que un sitio se comporta como un ser vivo que crece y evoluciona. La publicación inicial es como el Nacimiento. Luego, su vida es cíclica. Diseño, Implementación, Publicación, Evaluación, y vuelta a comenzar.

Las razones

Atención: este Método no garantiza de ninguna manera que el sitio funcione o sea bueno (encontrará más sobre esto en el documento de evaluación de sitios). Este método, ayuda a:

  1. que el sitio exprese realmente lo que sus autores desean y que...
  2. ...los recursos disponibles –humanos, económicos, tecnológicos, etc.– sean utilizados de manera óptima en el contexto del desarrollo.

Concretamente, lo hace permitiendo:

¿Qué necesito para utilizar el Método?

Para desarrollar un sitio, lo primero que debemos tener es la gente adecuada.
¿Quiénes son los afortunados? ;-)

Básicamente, deben existir dos equipos:

  1. El Comité de Publicación
  2. El Equipo de Desarrollo

Ambos equipos pueden –y suelen– tener gente en común. Es más, los integrantes de ambos equipos pueden superponerse en gran proporción.

Armar los Equipos

Comité de Publicación

El Comité de Publicación (CP en adelante) es el responsable de llevar adelante las líneas generales del proyecto (objetivos, audiencias, contenidos) y de aprobar los resultados para avanzar en el desarrollo.

El CP debe tener un representante de cada área o departamento involucrado y expertos en el tema –o temas– del sitio.

Por ejemplo en una empresa puede haber una persona del área de Marketing y Comunicación, otro integrante de Atención al Cliente, algún ingeniero de producto, etc. Además, debe haber un representante del equipo de Desarrollo para ubicar las propuestas dentro de un marco lógico –desde lo técnico– teniendo en cuenta los márgenes de tiempo y recursos disponibles.

En general, grupos de entre 3 a 5 personas están en un punto adecuado para tener variedad y riqueza de enfoques. Más integrantes pueden hacer que la operatoria se haga lenta o ineficiente o que sea imposible llegar al consenso.

Si bien no es el ideal de ninguna manera, el CP podría estar integrado sólo por una persona, que podría, incluso, ser Project Leader y Coordinador del Equipo de Desarrollo al mismo tiempo (claro que para poder hacer esto, debería saber mucho de muchas cosas...).

Equipo de Desarrollo

El Equipo de Desarrollo (ED en adelante) es el responsable de llevar a la práctica e implementar las decisiones del Comité de Publicación. A su vez, le da forma al proyecto, a través de su representante en el CP, brindando soporte desde lo técnico y ayudando con la planificación.

El ED está compuesto por los que efectivamente implementan el sitio: redactores, marcadores (de HTML1), diseñadores gráficos, programadores, un coordinador, etc.

La cantidad de profesionales del Equipo de Desarrollo es directamente proporcional al tamaño del proyecto. Un equipo mínimo puede tener 3 personas (redactor/marcador, diseñador gráfico, programador).

Dos consejos respecto de la gente

Uno:
Atención a quiénes cumplen estas funciones en sus grupos hoy y Ud. no lo sabe. Esa gente vale oro.

Así como en cada oficina siempre hay un gurú de las computadoras –ése al que todo el mundo le pregunta cuando tiene algún problema– suele también haber alguien que sabe dónde está la información adecuada, así como alguno que quizás marca en HTML. Busque, busque, y se ahorrará mucho en tiempo de capacitación y de desarrollo y, de paso, aumentará la felicidad de su gente en particular y del Universo en general.

Dos:
Provea a la gente de las herramientas necesarias. Además del software necesario –un tema que hoy no es problema– me refiero especialmente al tiempo. No se puede pedir que alguien se dedique a llevar el proyecto de un sitio o a colaborar en su desarrollo además de seguir con las tareas que lleva a cabo normalmente (que usualmente ya vienen desbordándolo).

Aprender los pasos del Método

La segunda misión que debe cumplir, luego de reunir a la gente adecuada, es aprender los pasos y comprender el porqué de cada etapa y tarea del Método.

A veces, las ganas de empezar a producir y de tener algo para mostrar a sus pares o a otros responsables "ya mismo", hacen difícil seguir ordenadamente los pasos y pueden echar por tierra con la inversión inicial de paciencia y energía.

Entender los pasos del Método es, además, necesario para poder adelantarse y preparar el material de las tareas que siguen.

Esto reduce los tiempos muertos en la producción.

Hemos visto muchos casos donde el trabajo de 5 personas, que se cumplió a tiempo, quedó esperando días o hasta semanas porque la sexta persona no tenía preparado lo que debía.

Evaluar en cada etapa

Nunca lo diré suficientes veces. Evalúen constantemente el estado del proyecto contra el planificado, no sólo en lo que a los tiempos se refiere sino, por ejemplo, en lo relativo a las estimaciones sobre provisión de contenido.

Las desviaciones del proyecto planificado inicialmente no necesariamente son malas. Quizás nos sirven para darnos cuenta que hicimos estimaciones demasiado positivas o demasiado negativas.

De estas diferencias se puede obtener un índice de corrección que podemos aplicar la siguiente vez que hagamos una estimación similar.

Ejemplo: si creímos que la provisión de contenido nos tomaría 20 días y tomó 30, tenemos un coeficiente de corrección de:

30 días / 20 días=1.5

En la siguiente estimación, si calculo que el trabajo tomará 10 días, deberé ajustar este valor con el índice calculado, y quedará:

10 días x 1.5 (coeficiente de corrección)=15 días

Este tipo de evaluación se refiere a la planificación. Pero hay otras evaluaciones tan importantes como éstas: son las de usabilidad.

Los tests de usabilidad se pueden –y se deben– llevar a cabo tan tempranamente como sea posible y es posible hacerlos sobre prototipos en papel. Esto ayuda a corregir errores en el diseño antes de que haya comprometida una gran cantidad de horas/hombre y que los cambios se vuelvan costosos en tiempo y esfuerzo.

¿Mencioné antes que se debe evaluar constantemente el estado del proyecto contra el planificado? ;-)

Ser honesto

Si el sitio es sólo para que el Gerente General esté contento, sean claros y háganlo con ese objetivo. A la larga, si tratan de hacerlo de otra manera, malgastarán tiempo, dinero y esfuerzo y no engañarán a nadie.

La típica "página institucional" no sirve de mucho. Denle a los usuarios algo útil.

Si no les gusta el proyecto o no creen que son capaces de hacerlo, pongan a otros a cargo.

[ Ir a la Tabla de contenidos ]


El Método

¿En qué consiste el Método?

El Método es un ciclo de 4 etapas a seguir en un cierto orden que, una vez terminadas, se vuelven a repetir.

Las etapas son: Diseño, Implementación, Publicación y medición, y Evaluación.

Espiral con etapas del método.

El método se parece más a una espiral que a un círculo porque cada ciclo crece e incorpora los resultados del anterior.

Cada etapa –que cierra la anterior y prepara para la siguiente– consta de una serie de tareas que se deben cumplir. A su vez, cada tarea está compuesta por varios procedimientos.

Las Etapas

Anteproyecto

El Anteproyecto se hace sólo al comenzar el proyecto. En el gráfico figura como etapa 0.

Su objetivo es delimitar y estimar gruesa –pero correctamente– el proyecto.

Para ello se hace un relevamiento preliminar de la información disponible y un par de reuniones con el CP.

A partir de ahí, se documentan los objetivos del proyecto, su audiencia, su alcance, el contenido y la organización inicial propuesta, así como su posible evolución a lo largo del tiempo y otros temas vinculados (la estructura de e-mail relacionada con el sitio o requerimientos externos como la recolección de información necesaria de terceros no participantes en el proyecto).

Todo esto conforma la propuesta inicial con la que se pueden estimar plazos y costos, aunque con una variación porcentual grande, quizás de hasta el 30%.

El anteproyecto nos ubica en un punto de partida común a todos los integrantes del proyecto y nos permite comenzar a calendarizar y reservar tentativamente los recursos (humanos, tecnológicos, económicos, etc.). Así, cada integrante puede comenzar a prever su participación y obligaciones.

Diseño

En esta etapa, pensamos, creamos, mostramos y discutimos.
Nuestra actitud es meditativa y preparatoria.
Comenzamos en Yin pero nos estamos moviendo hacia Yang.

En la etapa de Diseño se hace un relevamiento exhaustivo de los requerimientos del proyecto y de la información disponible.

Se documenta todo, pero sin llegar a implementarlo y se somete el proyecto a pruebas y revisiones hasta su aprobación por parte del CP.

El resultado de esta etapa es un documento –el Manual del Sitio, análogo a los manuales de gráfica para la imagen corporativa– donde se describen todos los detalles de su estructura, su funcionalidad y su implementación, acompañados de muestras para su evaluación, llamadas prototipos.

Esta documentación permite:

Idealmente, la implementación debería ser independiente del diseño si la documentación generada fuera perfecta.

¡Atención! Muchas veces, para proyectos de gran alcance, el diseño se hace teniendo en cuenta todo el horizonte de desarrollo, pero la implementación puede realizarse por etapas.

En la vida real esto se expresa en un documento donde se especifican muchas áreas de contenidos o funciones, pero se explica que, por ejemplo, en el primer semestre se implementarán sólo las áreas A y B, en el trimestre siguiente C y finalmente, D...

Éstos son algunos puntos que deben estar especificados en el Manual de Diseño.

Meta, objetivos y audiencia

Si no somos capaces de especificar claramente la meta y los objetivos del sitio, es porque no los tenemos claros. La especificación debe ser clara, concisa, concreta y en lo posible, medible.

Por ejemplo, es mejor tener como objetivo "Brindar soporte al usuario, facilitándole el acceso a la información y a los programas relevantes" que simplemente "Ofrecer valor agregado". El primer objetivo no sólo es más concreto: también se puede medir3.

La audiencia debe ser especificada como grupos de personas con características definidas. Por ejemplo, es mejor "Abogados y Contadores" que "Profesionales".

Cuanto más detalladamente se pueda caracterizar a la audiencia, mejor se podrá ajustar el lenguaje, la organización del contenido, etc.

Normativas

A lo largo de la etapa de Diseño se desarrollarán varias normativas que brindarán un marco general coherente al sitio.
Las más importantes son:

Las normativas no sólo brindan solidez sino que además reducen el tiempo de desarrollo al armar el marco general que, de esta manera, no debe ser repensado o redesarrollado cada vez que se agrega nuevo material.

Desarrollo de prototipos

Una vez definidas las normativas generales –o incluso durante su desarrollo–, se pueden hacer prototipos.

Estos prototipos permiten "ver" el sitio antes de hacerlo y, por lo tanto, asegurarse de que todos estamos de acuerdo en lo que haremos. Además, es posible probarlo con usuarios reales.

Existe una técnica muy interesante y nada cara llamada diseño iterativo de prototipos en papel. Si, leyó bien, en papel. Con dibujitos que simulan lo que se verá en la pantalla.

Estas pruebas nos permiten ver posibles errores u omisiones antes de que el sitio esté armado, momento en que la inversión ya fue hecha y es difícil y costoso cambiarlo.

Definición de criterios de evaluación

Durante la etapa de diseño se deberían fijar criterios para evaluar el funcionamiento del sitio. Algunos pueden ser difíciles de medir con números, pero es mejor tener criterios difusos que no tenerlos. :-)

Siguiendo con el ejemplo anteriormente citado de "Brindar soporte al usuario, facilitándole el acceso a la información y a los programas relevantes", es posible realizar una medición en forma de una encuesta para ver cuántos clientes han utilizado el servicio de la bilbioteca de drivers o solucionado problemas con un troubleshooting en línea. También se pueden cruzar estos datos con un análisis de los logs del servidor4, para ver cuántos hits tiene la sección o la página de drivers (más información en análisis de accesos).

Otros criterios de evaluación, tales como el grado de satisfacción del Cliente, pueden ser medidos con los métodos tradicionales que usualmente usa la organización, como las encuestas personales, por carta o e-mail, o encuestas en los eventos.

Implementación

En esta etapa, hacemos, generamos cosas y objetos.
Nuestra actitud es activa. Tenemos un carácter decididamente Yang.

En la etapa de Implementación se hace real, se desarrolla y se lleva al servidor todo lo especificado en el Diseño.

A continuación, describimos algunas de las tareas más importantes de esta etapa.

Implementación

Se redactan o adaptan los textos; se marca en HTML; se hace toda la gráfica desde los marcos generales hasta las imágenes individuales de cada página.; se programan las consultas a bases de datos si las hubiera; se conectan los formularios a sus respectivos scripts, se instala y se configura el software de base en el servidor, etc.

A medida que se va produciendo material, se ensamblan las partes del sitio. El texto se marca y se arman páginas en HTML; se les agregan las imágenes y sobre templates marcados de muestra se programan los scripts.

En proyectos de gran alcance, esta tarea puede hacerse por partes. Es decir que primero se implementan ciertas secciones para la salida del sitio y luego se van agregando otras a medida que pasa el tiempo y vamos teniendo datos sobre el uso y tráfico del sitio.

Una función muy importante del Coordinador del ED durante ésta tarea es la llamada "Control de Versión".

El Control de Versión consiste en la autorización a cada integrante del grupo para trabajar en un documento dado, y el seguimiento de esa autorización.

Esto es especialmente importante cuando varios profesionales trabajan sobre el mismo cuerpo de documentación.

Supongamos que un tal Pablo envía un documento para corregir a sus compañeros Manuel y a Graciela. Si Manuel lo termina justo antes que Graciela y ambos lo envían a Pablo casi al mismo tiempo, se corre el peligro de que las correcciones de Graciela "pisen" el trabajo de Manuel. Además, sería dificultoso comparar versiones que pueden tener correcciones en la expresión en secciones en las que otro cambió la estructura.

Para ello, alguien decide que primero va a Graciela y sólo cuando su versión se compara con la original, se envía a Manuel el resultado de esta comparación (con sus correcciones aceptadas o rechazadas).

Implantación

En general, el desarrollo no se hace directamente en el servidor donde residirá el sitio. Entre otras razones, por seguridad, diferencias en la disponibilidad de los sistemas operativos de las herramientas y porque muchas personas colaboran al mismo tiempo con diversos módulos del sitio.

Se llama Implantación entonces al proceso de transferir todos esos módulos, desarrollados en partes relativamente independientes, al servidor y al de hacerlos funcionar en el entorno en el que residirán y se usarán finalmente.

Suele pasar que pequeñas diferencias en las versiones del software, como por ejemplo en el servidor de bases de datos, hacen necesarios toques mínimos para ajustar definitivamente las aplicaciones a su entorno definitivo.

Pruebas

Cuando el material (programas, páginas en HTML, gráfica, etc.) está finalmente implantado, se deben hacer las pruebas finales. Algo así como el ensayo general con el vestuario, la música y todo.

Esto debe hacerse con usuarios reales. Uno jamás puede imaginarse las cosas interesantes que un Usuario ignorante del desarrollo puede descubrir... :-)

Publicación y medición

En esta etapa, observamos y medimos.
Nuestra actitud es contemplativa.
Estamos pasando del Yang hacia el Yin.

Esta etapa comienza formalmente en el momento en que el sitio se hace accesible al público. En el caso de una Intranet, "el público" se refiere a los usuarios fuera del grupo de desarrollo.

Publicación

La publicación puede comenzar con un cambio de permisos o de directorio en el servidor5. Sin embargo, nadie visitará un sitio que no sabe que existe.

Difusión

La difusión es una actividad que hace que la audiencia conozca la existencia del nuevo sitio y la alienta –o la tienta– a visitarlo.

Los medios a su alcance son muchos: Los de advertising tradicionales (gráfica, radio, televisión); los medios dentro de Internet, que son participación en listas y newsgroups, intercambio de links, banners, etc.

Además de los medios externos, hay un mensaje constante que debería ser emitido por la organización o empresa con su documentación y papelería. Al lado del teléfono o fax, la dirección genérica de e-mail; pegado a la dirección postal, el URL del sitio (la dirección en la Web).

Así como los individuos tienen sus tiempos propios para aprender nuevos usos y nuevas tecnologías, las organizaciones y empresas también los tienen. Esos tiempos son mucho más que la suma de los tiempos de los individuos que las componen.

Una estrategia que está absolutamente prohibida para difundir un sitio es el spamming, la oferta no solicitada de servicios comerciales vía e-mail. El hecho de que esta estrategia se esté tornando habitual no la hace aceptable (para más información, ver http://www.cauce.org)

Análisis de accesos

En cuanto el sitio se hace público, se deben comenzar a analizar los accesos al sitio4. Existe software específico para ello. Algunos de los datos que se pueden analizar son patrones de acceso por día, hora y archivo, browsers utilizados para acceder al sitio, dominios desde los cuales se accede, etc.

Todos estos datos nos permiten armar una imagen de quiénes y cómo están utilizando nuestro sitio.

Encuestas

Las encuestas son un medio tradicional que, en este caso, simplemente pueden tener algo más de facilidad por los medios como el e-mail, que facilitan la recolección y procesamiento de datos.

En las encuestas pueden incluirse análisis relativamente informales de los tipos y cantidad de e-mails generales desde/por el sitio.

Tests de usabilidad

Los tests de usabilidad merecen un documento completo aparte.

Pueden hacerse desde antes de la publicación del sitio; si no lo hizo hasta ahora, éste es el momento para comenzar.

Así podrá saber si muchas características de los usuarios y del sitio que asumió como ciertas al comenzar con el desarrollo (por ejemplo, conocimientos técnicos de sus usuarios, interés o utilidad relativa de las diferentes áreas de contenido) son verdad o no.

Si no lo fueran, podrá ver qué y cómo cambiar.

Evaluación

En esta etapa, meditamos y aceptamos.
Nuestra actitud es creativa, abierta y flexible. Estamos en Yin.

O.K, ya salió el sitio; ya ha comenzado a ser utilizado. Hemos recolectado información variada acerca de su uso y su percepción por parte de los usuarios.

¿Y ahora?

Ahora analizamos las posibles razones y/o consecuencias de todo esto y usamos esta información para recomenzar con el diseño.

Análisis de los datos obtenidos

Números aparte, ¿qué significa que mi patrón de accesos horarios tiene picos en horarios no comerciales? ¿Qué conclusión podemos sacar si tenemos muchos accesos que no son de dominios.ar? ¿Qué puedo –o no– hacer si tengo soporte de hojas de estilo en el 70% de los browsers que acceden a mi sitio?

Comenzamos a pasar de la sorpresa por los datos imprevistos (siempre los hay) a tratar de extraer alguna conclusión o conocimiento útil de ellos.

Comparación con los criterios establecidos y verificación de las diferencias

Tenemos los datos. Esto es la realidad. Pero nosotros habíamos planteado una serie de objetivos que queríamos cumplir.

¿Alcanzamos los objetivos? ¿Dónde no? (estos puntos pueden ser los más reveladores). ¿Tenemos idea de qué puede haber generado la diferencia entre los que creíamos que iba a pasar y lo que pasa?

Estos datos se usan para generar las...

Decisiones para el próximo rediseño

Ahora sabemos, o creemos saber, qué cambiar para acercar esta realidad a nuestros objetivos.

O quizás vemos cosas que no habíamos anticipado y no son necesariamente problemáticas, sino todo lo contrario. Quizás no previmos que cierta información que creímos que no era tan importante, tiene una cantidad de accesos inesperada. Quizás podemos usar esto como "gancho" para armar nuestra imagen de empresa conocedora de su tema.

En este estado nos encontramos. Ahora es cuando corresponde comenzar nuevamente el segundo ciclo de la evolución del sitio con una nueva etapa de Diseño.

[ Ir a la Tabla de contenidos ]


Una vez que terminamos con el desarrollo inicial

Volvemos a la etapa de Diseño. Pero ahora no es necesario armar un anteproyecto y somos un poco más sabios y humildes. Conocemos nuestros objetivos (que quizás fueron modificados por la experiencia) y sabemos un poco más en qué nos acercamos a ellos y en qué nos equivocamos al tratar de hacerlo.

¿Y ahora?

Ahora que sabemos cómo se desarrolla un sitio en la Web (y seguro saldremos todos a practicar mucho, porque la práctica hace a la perfección), en otro documento veremos cómo evaluar el desempeño de un sitio en la Web desde varios puntos de vista.

[ Ir a la Tabla de contenidos ]


Ejemplo práctico del método: La Asociación de Amigos del Tranvía

Supongamos que la Asociación de Amigos del Tranvía quiere hacer su Web site6.

Supongamos, también, que conocen este método y sus maravillosas ventajas, y que lo siguen escrupulosamente. Veamos su experiencia.

Lo primero es armar los equipos. Para ello, determinan que el Comité de Publicación (CP en adelante) estará formado por:

El Equipo de Desarrollo (ED en adelante) estará formado por personal externo contratado, a saber:

Registran y delegan el dominio aat.org.ar. El nombre de este dominio surgió de la siguiente manera: aat, por "Asociación de Amigos del Tranvía", org, por ser un ente sin fines de lucro y ar, por ser una organización Argentina.

A continuación, los miembros del CP arman el anteproyecto en el que establecen los objetivos del sitio como:

De estos objetivos, se desprende directamente que la audiencia estaría formada por:

El alcance del proyecto está delimitado a un sitio público en la Web, algunas cuentas de e-mail para la Asociación y una cuenta para cada Miembro de la misma.

Como el material es mucho y la Asociación desea ejercer cierto control sobre los servicios a prestar (como el e-mail para los miembros o accesos a información restringida para socios) y, en el futuro, hacer áreas de trabajo internas (no públicas), decide implementar una solución de housing (servidor propio conectado a la red del ISP y físicamente localizado en la casa del ISP), sin conexión punto a punto a la sede.

A continuación, con la ayuda del Maestro de Archivos de la infoteca, el Historiador y el Ingeniero y, sobre la base de un relevamiento preliminar, el CP estima la cantidad de material total. El coordinador junto con los integrantes del ED estiman las horas/hombre requeridas para convertir y publicar ese material.

De estas estimaciones y algunas otras más específicas relacionadas con el diseño inicial, surge una estimación de plazos y costos.

Con esta estimación aprobada por el CP, comienza la etapa de Diseño.

Se ratificaron los objetivos y la audiencia.

Se releva el material existente –todos los integrantes de ambos equipos– y a partir de ese relevamiento se proponen metáfora, organización y gráfica.

Se decide utilizar la metáfora de un viaje en tranvía a lo largo de varias líneas con sus respectivas estaciones para presentar el sitio.

Se desarrollan 3 propuestas gráficas, de las cuales se elige una que gustó especialmente, con algunos detalles de las otras. Esta propuesta se desarrolla en mayor detalle con varios prototipos que se evalúan con futuros usuarios del sitio. Se decide finalmente por una de las variantes; se generan con ella las muestras de la página inicial, una página tipo de cada sección y la decoración especial de cada Estación.

En paralelo, se arman las normativas de la redacción (teniendo en cuenta el material existente y el estilo deseado por el CP) y las técnicas (teniendo en cuenta el servidor y el estado de los estándares abiertos de la Web, ver http://www.w3.org), entre otras.

Luego de analizada la información disponible y los objetivos del sitio, se decide dividir inicialmente el sitio en las siguientes secciones o Líneas7:

El Tablón de Avisos está disponible desde todas las páginas así como la Oficina Central (ver los objetivos del sitio). También la Estación Central y el enlace al Museo.

Inicialmente, se implementarán la Línea de la Asociación y un pequeño porcentaje de la Línea del Museo. Luego de un trimestre de la publicación del sitio y con más datos, se seguirá ampliando la Línea del Museo con mas estaciones.

Se define una organización interna del servidor análoga a la de los contenidos. El HTML será version 4.0 transicional de marcado estructural enlazado con hojas de estilo de nivel 2 (CSS2). Se permite el uso de JavaScript pero, ya que no parecen ser necesarias por el momento y hasta tener más datos, no se utilizarán aplicaciones desarrolladas en Java.

Al comenzar con la implementación, se digitalizan los textos, imágenes y films existentes. Se adaptan los textos y se genera nuevos hipertextos e imágenes, quizás algunas animaciones para explicar el funcionamiento de determinadas maquinarias del circuito del tranvía eléctrico.

Se ensamblan todas estas partes siguiendo el cronograma planificado. Se detecta un atraso de aproximadamente un 15% respecto del tiempo planeado y se ajusta el tiempo restante y las fechas, contando con esta cantidad adicional de tiempo. Como se quiere publicar el sitio para la fecha de la International Tranway Expo en París, se decide disminuir algo de material de ambas líneas quitando una Estación de cada una (la menos importante), para que queden proporcionadas.

Con el sitio desarrollado, se deciden algunas modificaciones de último momento. Para tranquilizar a los miembros Asesores del CP y conocer sus críticas, se imprime parte del sitio y se reparte para que puedan hacer las correcciones sobre papel. Como los textos se repartieron para su aprobación antes de ser finalmente ensamblados con las imágenes, no hay casi correcciones.

Se implanta el material en el servidor y se hacen pruebas con 5 usuarios.

En base a los resultados, se cambia la redacción de algunos botones y se reorganiza el contenido de la Estación de Ingeniería (no resultó fácil entender algunos conceptos sobre tensiones). Además, se agregan links directos desde la página inicial a ciertas secciones con material que se espera que sea interesante para la audiencia.

Finalmente, con algo menos del contenido ideal, pero en fecha, se publica el sitio 24 horas antes de la International Tranway Expo.

Durante la expo, que dura 7 días, se publicita y difunde el sitio en el Stand de la Asociación. A lo largo de esos días se recogen datos en los logs del servidor, de tests informales realizados entre los asistentes y de una corta encuesta pre y post test.

Antes de comenzar, se les pregunta a los asistentes qué esperan y qué desean encontrar en el sitio de la Asociación, en qué circunstancias pasearían por el sitio si no fuera en la Expo y cuánto tiempo creen que le darían.

Durante el test se les pide que busquen un determinado dato en el sitio, que comparen cierta informacion y otras tareas semejantes.

Luego del test, se les pregunta cuánto vieron de lo que querían, si modificarían algunas de sus respuestas del principio, algunos otros detalles sobre su apreciación general del sitio y algunas áreas particulares (¿la información sobre tal tema es poca, suficiente o demasiada? ¿qué sensacion le queda del estilo gráfico? ¿diría que su experiencia lo ha enriquecido poco, mucho o nada respecto de sus conocimientos sobre el Tranvía?).

A cambio de los minutos de test y de su atención, se les regala un prendedor metálico con una réplica de un Tranvía clásico de 1902.

Ya en el segundo día es claro que hay algo que no funciona. Si bien no se trata de algo incorrecto, es una omisión inesperada: para una audiencia internacional (que no es la planteada en el diseño pero es la que se pudo observar en este período y resultó de interés) falta información sencilla acerca de Argentina y especialmente del Buenos Aires de principios de siglo. Esto provocaba una descontextualización de la información que reducía la apreciación del interés histórico del tranvía y hacía difícil su comprensión.

Se envió esa información a Buenos Aires, donde el ED puso en línea 24 horas más tarde unas pocas páginas con la síntesis social, geográfica y económica requerida. No era la ideal, pero las pruebas de los siguientes días mostraron una clara reducción en el problema de la desorientación geo-histórica.

Luego de la Expo, llegados los representantes de la Asociación a Buenos Aires y repuestos tras unas siestas extraordinarias, se hace una reunión ad hoc para evaluar el desempeño del sitio.

Durante la reunión se exponen los resultados antes y después del agregado de las páginas de historia, se comparan con las expectativas iniciales y se analizan las posibles razones o consecuencias de las diferencias.

Se llega a la conclusión de que:

Las decisiones que guiarán el rediseño del sitio en su próxima etapa de evolución se corresponden con bastante aproximación una a una con los hechos detectados y son:

[ Ir a la Tabla de contenidos ]


Esto es todo amigos.
Espero que nuestras experiencias los ayuden con vuestros procesos de desarrollos de web sites en particular, y de publicación electrónica en general.

Dudas, críticas y comentarios son bienvenidos como siempre a edumerco@gaiasur.com.ar.

Hasta la vista... :-)


Notas:
  1. El HTML se "marca", no se programa.
    (volver al texto)
  2. Un caso especial de esto son las pruebas de usabilidad para un sitio que consisten simplemente en tareas reales probadas con usuarios del sitio.
    (volver al texto)
  3. Uno de nuestros clientes tenía, como mínimo, tres mensajes diarios con pedidos de drivers. Cuando pusimos en línea una biblioteca de drivers, sólo quedaron uno o dos pedidos por semana, que correspondían a gente que no había visto la nueva sección o que pedían drivers extraños que por alguna razón no están en la biblioteca.
    (volver al texto)
  4. Los servidores http guardan los datos de todos los pedidos, sean para una página en HTML, una imagen, un script o cualquier otro recurso del servidor. El registro de estos datos es el log.
    (volver al texto)
  5. Para los técnicos, la publicación también puede hacerse con un cambio en el DNS responsable del dominio que enviaba los pedidos a otro número IP y ahora apunta al servidor designado con el sitio funcional.
    (volver al texto)
  6. Este ejemplo es inventado tomando partes de proyectos realizados. Toda similitud con la realidad es pura coincidencia o deseo. ;-)
    (volver al texto)
  7. , En realidad, toda la información se relaciona con la que corresponde, ya que el sitio no es una serie de menúes sino un hipertexto. Sin embargo, la división en áreas permite a quien no conoce el contenido, acercarse gradualmente al él.
    (volver al texto)