control paginas web

Desde el advenimiento de la navegación a través de Internet, se ofreció al mundo la posibilidad de ingresar en un plano informativo donde la creatividad y la informalidad en las formas iniciaron su camino tomados de la mano. Muy pronto se vislumbraron las apetencias de los usuarios de la Red, los cuales comenzaron a ser cada vez más exigentes y a demandar calidad en los servicios y en las características de los sitios WEB.

Si bien es cierto que la tecnología en Internet avanza día tras día, esto se constituyó en un factor condicionante por el spread de visitantes, quienes con las facilidades del momento al alcance de la mano dieron rienda suelta a su imaginación y a la valoración estético-funcional de los sitios. Pasada la etapa inicial donde los errores eran producto de una lógica improvisación por parte de Webmasters más entusiastas que técnicos, continuó un ciclo de estabilización basado en el perfeccionamiento. Contra toda lógica, persisten sin embargo errores en los sitios actuales, producto más del trabajo urgente que del diseño en sí mismo, sin descartarse los desaciertos de construcción que se ven a menudo.

Partiendo de la base de que un sitio WEB es un verdadero software, éste no escapa a las generalidades de los software y es pasible por lo tanto de ser sometido a pruebas de aceptación, a test de capacitación, y a pruebas de stress funcionales que tengan un grado de exigencia afín con el objetivo del diseño.

Con la finalidad de establecer una reseña de los errores más frecuentes vinculados con el software de un sitio WEB, se describen a continuación las distintas variables que se deberían tener en cuenta para construir un "CHECK-LIST" de control previo a todo lanzamiento, trabajando sobre casos verídicos, e ilustrando cada caso en la medida de las posibilidades.

Como en toda obra que involucre un proceso creativo, existen dos componentes: el fondo y las formas. En este trabajo no se han tenido en cuenta los contenidos de los sitios. Debido a que la calidad de los contenidos es todo un tema que se encuentra en pleno auge de análisis sobre si "es necesario o no realizar un control de calidad de los contenidos de un sitio para otorgar garantías de confiabilidad de la información presentada", ésto ha sido momentáneamente dejado de lado para dedicarnos al análisis de las formas de presentación de la información, tema principal de este trabajo.

Considerando que una página o un sitio WEB constituye un verdadero software, hemos de enunciar los principios y/o definiciones existentes en materia de control en proyectos de software, aplicables también a los sitios WEB.

Control de acceso: Sistemas de protección para que las aplicaciones sean invulnerables a las agresiones accidentales y/o intencionales que puedan producir modificaciones, destrucciones, fragmentaciones, pérdida de la información, etc. Trata especialmente las formas de evitar el acceso no permitido al sistema.

Complacencia: Seguridad de que el software, (en este caso los sitios WEB) está construído según los objetivos, políticas, standares, métodos organizativos, procedimientos, previamente diseñados, y que estén identificados, implementados y mantenidos en conjunción con los requerimientos de otras aplicaciones.

Facilidad de uso: Esfuerzo necesario para aprender , operar, conocer, y preparar el ingreso de información a un sistema (input), y la interpretación correspondiente de los datos egresados del mismo (output).

Mantenimiento: Esfuerzo necesario para ubicar un error en un sistema operacional. El concepto de error involucra no sólo un defecto en el sistema, sino también la mala interpretación de los requerimientos del usuario.

Una de las características mas relevantes en materia de calidad es el Giro de Actualización de sus páginas. Un sitio con actualizaciones frecuentes posee un valor muy alto a la luz del análisis de sus contenidos, y favorece el retorno del visitante. Pero para que éste sepa que la información es actualizada, debe citarse la fecha del último update en forma clara y en un lugar bien destacado dentro de la página. Este detalle debe verificarse en todas las páginas de un sitio, y no solamente en el Home Page, ya que lo que interesa como muestra de calidad es la fecha de actualización de la información puntual y no del sitio en su totalidad.

En términos generales, ya que posteriormente serán analizados por separado, los links, las imágenes, las funciones de las páginas dinámicas, constituyen el núcleo de la estructura de calidad. Si bien es cierto que existen en el mercado vinculado con la Informática diversos programas de Software que permiten detectar alteraciones en el funcionamiento de los hipervínculos de un sitio, la práctica diaria indica que la evaluación personificada mediante navegación y prueba de todos los links permite detectar links que no funcionan por mal direccionamiento, fotos que no se abren por irregularidad en la denominación de los respectivos archivos, links que apuntan a páginas diferentes de las que deberían señalar y que no cumplen su rol de direccionamiento, etc. Estos inconvenientes seran tratados en detalle en el capítulo siguiente.

Los contenidos de un sitio constituyen uno de los puntos álgidos de la cuestión. Si bien como demostración de Software, un sitio WEB cumple con las especificaciones en la materia, en la mayoria de los sitios WEB se puede producir una colisión entre las características arquitectónicas del mismo y los contenidos que el público espera. La disarmonía entre contenidos y formas de presentación constituyen un diario problema dramático de la relación entre Webmasters y Jefe de Contenidos de un emprendimiento de Internet. Sin ánimo de pretender establecer un órden de jerarquias, la justa administración de los recursos disponibles en materia de contenidos debería estar acompañada de una forma de presentación acorde al estilo del sitio, pero especialmente teniendo en cuenta la población blanco hacia la cual la página va dirigida.

La calidad de los contenidos entre una versión y otra, ya significa una evaluación e interpretación de los mismos. Tecnicamente debemos vigilar que los contenidos presentados correspondan al título de la página, como demostración de que los links o jumps dentro del sitio en estudio están bien coordinados y que no existen cruzamientos entre el archivo llamado y el contenido esperado. Aunque parezca extraño, uno de los errores que a veces se cometen es el olvido de efectuar el upload de un determinado archivo de contenidos, de forma que al accionar un link nuestro browser no puede localizar el archivo deseado.

Es suficientemente exacta la pagina que se va a mostrar al visitante? Para ello es necesario obtener la información por otra vía distinta de exactitud comprobada. La exactitud y consistencia la debemos evaluar mediante el control periódico de la misma página, de forma tal de poder analizar la última version de la misma página en linea de base y en el sitio de producción.

Considerando que el factor tiempo es uno de los mas observados por los navegantes de Internet, la respuesta de tiempo y latencia constituye un punto crucial en la evaluación de un site. Para ello se deberá testear distintos tipos de conexiones (dial up; conexión fija de diferente ancho de banda; ISDN, etc). Pero estos distintos medios de conexión a Internet solamente nos van a dar una información relativa entre ellos. Para comprender los resultados en forma standard es necesario standarizar el sistema de medición. Una de las formas mas útiles y objetivas es la medicion del tiempo de latencia en forma offline, en dos equipos conectados en una red LAN. De esa forma, se realiza en un equipo la navegación de una pagina WEB ubicada en el otro equipo. Standarizando de esta forma el sistema de conexión, se puede obtener una apreciación del tiempo de apertura de la página en forma independiente del tipo de conexión, eliminando toda otra influencia externa vinculada con la ruta que la información sigue durante la conexión online.

Posteriormente, se podrán extraer conclusiones sobre funcionamiento online, aunque para ello se debería valorar previamente dicho sitio en otros tipos de conexiones y en horas de carga variable, en un rango de escaso a intenso tráfico.

No debe olvidarse que para una evaluación de respuestas de tiempos de latencia medidos a través de una conexión dial-up, se deberá vaciar los archivos temporarios de "cache" del browser utilizado, para lo cual hay que conocer el lugar donde el navegador almacena dichos archivos. Adicionalmente, se debe desactivar la opción de "utilizar servidor proxi", ya que de no cumplirse con estos requisitos se estaría midiendo el tiempo en condiciones totalmente falsas que llevarían a resultados sesgados. Sin cumplir estas exigencias, el tiempo medido no está tomando en cuenta a la nube de Internet, sino a las conexiones desde la PC del analista hasta el servidor proxi mas cercano. Excepción a esta regla lo constituye la visita por primera vez, pero si consideramos la necesidad de realizar varias evaluaciones en diferencias horas pico, comprenderemos que antes de cada evaluación se debe standarizar la prueba reseteando las condiciones mencionadas.

Realizando esta prueba en banco de laboratorio, y con la contraprueba en condiciones de conectividad por dial up deficientes, se podra detectar que la pagina evaluada no demore en abrirse mas de los clasicos 10 segundos denominados tiempo de desaliento.

La medición de los tiempos de apertura de las paginas pueden ser evaluados en forma global, o bien parcialmente. Un ejemplo de esto ultimo lo constituye la medición de apertura de determinados Applets de Java, lo cual a veces son el factor desencadenante de retardos apreciables en la navegación. Otras aplicaciones, como los plugins Flash y Shockwave, son causas de retardos a veces increibles.

Finalmente, para evaluar la performance deberemos controlar que el sitio WEB pueda comportarse en forma aceptable en cuanto al tiempo de apertura, aun exigido en controles a diferentes horas del día y con diferentes condiciones de tráfico, otorgando un rendimiento satisfactorio con el mínimo de recursos disponibles utilizados.

Como consideración general previo al análisis de las formas en materia de sitios WEB, debemos recalcar la necesidad de efectuar una evaluación que incluya la navegación con diferentes Browsers, no solamente por las diferencias en la navegación entre una y otra marca de software, sino entre diferentes versiones dentro de un mismo tipo de browser.

No debe olvidarse que todavía existen internautas que navegan con browsers antiguos, e inclusive algunos de uso muy limitado y casi desconocidos por las nuevas generaciones de navegantes. Esa población, aunque mínima, no debe ser subestimada en sus recursos ni discriminada hasta el punto de marginarla del acceso a la información.

Browsers como "Mosaic", "Lynx", "Opera", tal vez no compitan en la cuestionada discusión entre "Netscape" y "Explorer" en cualquiera de sus versiones, pero siguen siendo una realidad para las apetencias de sus seguidores.

No todo se reduce a los clásicos "Netscape" y "Explorer". Browsers como "NewBrowser" y "Neoplanet" constituyen claras demostraciones de calidad y potencia, asociadas a componentes de avanzada en las interfases gráficas que ya vienen incluidos.

Ante toda evaluación de funcionalidad de un sitio WEB, debería tenerse presente que una página que es concebida para funcionar con un solo tipo de navegador, indefectiblemente deberá ser corregida posteriormente, con los consabidos gastos adicionales y la consiguiente pérdida de tiempo que obliga a veces a soluciones apuradas con frutos muchas veces discutibles.

Finalmente, no debe olvidarse que existen otros sistemas operativos cuya difusión se encuentra en aumento, y que obligan a adaptarse a ellos; no evaluar la navegabilidad de un sitio construído bajo entorno Windows 98, utilizando un browser bajo sistema operativo Linux, puede deparar muchas sorpresas en el momento del lanzamiento. La inversa también.

En el presente capítulo se han evaluado diferentes aspectos vinculados con la arquitectura de un sitio, tanto en su faz estática como dinámica. Sabemos que la lista es interminable, pero hemos querido hacer una reseña mínima de errores que pueden ser perfectamente evitados mediante el juicio crítico de una correcta evaluación de las formas y su funcionamiento.

En ocasiones, un simple bracket faltante en un tag del código fuente puede hacer que el resto del tag aparezca en la pantalla del navegador como si fuera texto. Este error bastante frecuente lo podemos observar en la siguiente imagen.

Considerando que los tags determinantes de las funciones de sonidos difieren radicalmente en los dos navegadores mayormente utilizados por el público, se debería incluir en los sitios la sintaxis para ambos browsers. No hacerlo llevaría a la situación en la cual solamente navegando con cierto browser se podrán escuchar dichos sonidos.

Otra consideración vinculada con los navegadores, es la imposibilidad de ciertas versiones del "Netscape" para el funcionamiento de la marquesina. Debería ser testeado previamente, ya que de no ser reconocida esta función, el texto de la marquesina será expuesto como texto puro.

Este hecho bastante frecuente, se observa a veces como abuso de la función de escritura centralizada, y en ocasiones como error por la falta de un tag de cierre </CENTER> en el lugar oportuno, y ubicado al fin de la página.

La mejor forma de evaluar estos detalles es navegando el sitio desde su principio, y registrando detalladamente los errores encontrados para su posterior corrección. Existen software en el mercado que realizan evaluaciones similares en forma automática, pero la experiencia indica que tarde o temprano los sitios deben ser valorados mediante una prueba personalizada. La clásica imagen siguiente, no es más que el producto de una ruptura en la cadena de información que por una u otra causa lleva a desmerecer la labor de sus creadores.

En ocasiones este error no se debe a la ausencia del archivo con la imagen, sino a que por algún motivo el nombre dicho archivo fue capitalizado en su totalidad, o solamente en alguna de sus letras, generalmente la primera, mientras que en el código fuente persiste en minúsculas.

Otro error que habitualmente se observa, es la falta de las medidas de la imagen en el código fuente. Este pequeño detalle que permite que durante el proceso de carga el navegador continúe abriendo la página mientras que en el lugar de la foto persiste momentáneamente el espacio reservado para la misma, hace que al no cumplirse este requisito, el navegador deba esperar a que toda la foto sea descargada antes que se continúe abriendo el resto de la página, con el consabido retardo.

Obviamente, las fotos de extraordinario tamaño no hacen más que retrasar la descarga de las páginas, lo que puede ser obviado mediante la presentación de mini fotos con hipervínculo que sirvan de catálogo para llamar a las grandes.

Finalmente, uno de los errores más grandes, que obviamente se detecta merced a una revisión personalizada de todo el sitio, es la falta de coincidencia entre la imagen que se desea exhibir y la que realmente se muestra, producido no por un error en el código fuente sino por un error en la compaginación del sitio.

Un detalle generalizado, lamentablemente muy generalizado, es la falta de datos sobre la empresa que se está presentando en un sitio WEB. Algo tan simple como poner el nombre de dicha empresa o institución en un mínimo espacio al pie de página, generalmente es omitido por la mayoría de los sitios comerciales o institucionales. La falta de esos datos, no permite que el visitante conozca el origen del sitio, ni a qué institución pertenece. Algo tan elemental como el pais de origen, está ausente con increible frecuencia, al igual que el nombre del dueño en caso de páginas unipersonales.

Un detalle requerido por la mayoría de las opiniones profesionales de instituciones que presentan sus páginas con carácter informativo periódico, es que figure la fecha de la última actualización. Esto se aplica no sólo al home page y al sitio en su totalidad, sino a todas las páginas de actualización periódica. Lamentablemente ésto no se cumple en muchos casos, impidiendo así que se disponga de un dato vital en materia de información.

La presencia de disclaimers en pie de página donde se deslinden responsabilidades legales, no es un requisito para los sitios WEB, pero su utilización es francamente recomendable. Si la página posee un tinte francamente conflictivo, su uso es imperativo. Esto se puede notar en sitios vinculados con el e-commerce, la salud, el manejo de información bidireccional, etc. Debería ser incorporado en los protoclos de evaluación de los sitios.

1) Registro del dominio de URL. Generalmente no se exhibe porque al estar en uso el sistema de registro está implícito. En Argentina se realiza a través de NIC de Argentina, dependiente de la Cancillería. Para sitios en USA, se debe recurrir a empresas como Namesecure.

2) Registro del Nombre Comercial en Marcas y Patentes. Habitualmente ésto está exhibido al pie de la página con el signo © y la fecha adjunta. Su obtención es a través del Instituto Nacional de la Propiedad Industrial.

3) Registro del software (código fuente). En la Argentina se obtiene en la Cámara Argentina de Empresas de Software. Normalmente, en los sitios WEB no figura este registro que protege sobre las formas en que está construído un sitio WEB, y aunque teóricamente nadie podría hacer modificaciones de un código fuente de sitios en Internet sin conocer el password del titular para hacer el upload, es factible que alguien pueda modificar las fuentes offline, y editar un sistema de registro como un DKT o un CD-ROM con características abismalmente diferentes al de la página original.

4) Registro de Derechos de Autor. En la Argentina se efectúa en la Dirección Nacional de Derechos de Autor, y protege la propiedad intelectual de los contenidos de un sitio WEB. Como habitualmente los sitios tienen un ingreso de trabajos, papers, información, textos, imágenes, etc con cierta periodicidad, el registro de sus páginas debe ser periódico, y obviamente también debería estar citado al pie de la página.

Lo que nadie sabe a ciencia cierta, es a qué corresponde el signo © y la fecha que figuran al pie, ya que puede provenir de alguno de estos cuatro registros. Queda la incógnita, y la duda sobre cuál de ellos es indispensable citar.

Finalmente, los datos del Webmaster, del Postmaster, y canales de e-mail para poder vincularse con ellos para dudas u opiniones, deben estar en pie de página como las buenas costumbres indican. Si bien es cierto que algunas de estos temas no constituyen errores del software en sí, suelen ser errores cuando no han sido pensados o cuando se han subestimado.

La inclusión de textos en la construcción de sitios WEB constituye un verdadero arte, vinculado con el manejo de artes gráficas a la luz de la tecnología moderna. Pero existen pequeñas características derivadas del lenguaje HTML que hacen que el mejor diseño en banco de trabajo puede ser catastrófico en el momento de un lanzamiento sin haber tomado previamente la precaución de un riguroso análisis online.

El tamaño de letra elegido para cada caso, debe ser analizado y elegido con cuidado, teniendo presente el público al que va dirigido. Es frustrante visitar páginas donde la letra es tan pequeña que obliga a la gente de más de 40 años a tener que acercarse a la pantalla, y extremar el uso de anteojos. No todos los navegantes conocen la opción de adaptar el tamaño de las fuentes a sus apetencias. Si a esto agregamos una resolución inapropiada, la visita a dicho sitio será fugaz y el navegante huirá despavorido.

La presencia de fuentes de uso infrecuente, y no reconocidas por la mayoría de los navegadores, lleva a que los textos sean exhibidos en las fuentes marcadas por defecto en el browser en uso. Esto lleva a tener una imagen abismalmente diferente del aspecto del sitio, perdiendo mucho de su riqueza. Obviamente, utilizando Linux como sistema operativo esta situación se observa con más frecuencia.

La combinación del background y el color de la letra a veces no posee el contraste ideal para una lectura apropiada, y es frecuente observar sitios con fondo negro escritas en fuentes color bordeaux, cuya lectura es a veces muy difícil. En ocasiones, ésto ocurre solamente con el color de los hipervínculos visitados, y aquí sí estamos delante de un error de diagramación del sitio. Un link que en su forma original es letra amarilla sobre fondo negro puede ser aceptable, pero si el color del link vira al violeta oscuro una vez que se visitó dicho link, la lectura será indefectiblemente imposible.

El uso de imágenes como background resulta particularmente vistoso, pero siempre se deberá poseer un COLOR BACKGROUND básico para que en el caso de que por algún motivo la imagen no se pueda descargar, o tarde mucho en hacerlo, se pueda leer la página merced al fondo de color básico que le hayamos atribuido. Esto es particularmente necesario cuando el texto está escrito por ejemplo en letras claras sobre un fondo de imagen oscura, ya que de no abrirse la imagen, sería imposible leer letras claras sobre fondo blanco exhibido por defecto.

La presencia de un simple texto que remita al lector navegante a la página anterior o al comienzo de un texto generalmente extenso, suele estar ausente, y complica a veces la navegación. En ocasiones ésto está realizado con un botón, pero existen altas probabilidades de que este tipo de botones no funcione por errores en el hipervínculo. Los botones de "volver" y "top" son los que más frecuentemente no funcionan, y eso se debe a que escapan a las evaluaciones debido a que se testean solamente los botones de avance progresivo, y no los que vuelven o suben. Si bien es cierto que estos test son de larga duración y a veces se tornan cargosos, nadie obliga a realizarlos de urgencia ni por una sola persona. El tema es que el responsable, en su subconsciente no desea versiones beta, y pretende ser la persona que detecte los errores y luego los corrija sin demasiada trascendencia. Es para tener en cuenta.

Otro de los inconvenientes que habitualmente se observan es la aglutinación de excesiva cantidad de texto en páginas simples, sin tener en cuenta una diagramación de la escritura en una "caja" apropiada para el estilo de dicha página. Tanta sobrecarga de texto lleva a confundir al lector y a no permitirle identificar el área de texto leído ni los renglones.

No pretendemos ser tan críticos que no veamos la posibilidad de que cualquier persona pueda cometer esos errores, pero los controles de calidad y de ortografía están al alcance de todos. Debemos recordar que un simple texto puede desmerecer una hermosa página.

Los errores de tipeo suelen ser mas frecuentes. Y es interesante destacar la frecuencia con que dichos errores ocurren en los títulos o en sectores del texto que revisten crucial importancia. En la imagen siguiente podemos apreciar cómo una falta de tipeo aparece nada menos que en el nombre de la Organización del propio sitio.

Con el advenimiento de los nuevos plugins que permiten la visualización de efectos especiales, generalmente asociados a sonidos tales como "Shockwave" y "Flash", la descarga de páginas WEB a veces se torna dificultosa. En ocasiones debido a la relación entre archivos grandes y escasa conectividad permanente o circunstancial.

Debemos considerar siempre que no todos los navegantes tienen habilitados los plugins para ciertas funciones dinámicas, y que centralizar toda la información es sacrificar visitantes que no podrán observar la página como debieran.

Los Applets de Java mal escritos en forma manual por no haber sido copiados y pegados de la forma en que el fabricante recomienda, o archivos ".class " mal escritos con letras capitalizadas en forma diferente, impedirán que el efecto esperado se pueda realizar.

Las pantallitas de navegadores accesorias (Pop windows) que se abren simultáneamente con la página original de un sitio, mediante accesorios de Java o Javascript, deben ser de tamaño francamente reducido, ya que de abrirse de un tamaño similar a la pantalla original del navegador, el visitante tendrá dificultades para discernir cuál es la original y cuál es la accesoria a la hora del cierre de esta última. Para evitar esta dificultad, se sugiere que además del tamaño reducido esta pantallita posea un botón de "cerrar esta ventana", a fin de que el visitante la identifique sin dificultades.

Los formularios en CGI-BIN, por las características de constituir verdaderos programas a la ahora de su funcionamiento, deben ser cuidadosamente evaluados y probados mediante tests antes del lanzamiento. No solamente debe estar activa la funcion "POST", sino todas las accesorias, tal como el envío de la pantalla de agradecimiento.

Debemos recordar que en los casos de formularios de compra, registración, o en todo aquel formulario que implique una relación de envío de datos o que revista una situación contractual, se deberá incluir un TEXT AREA con texto pre escrito donde conste un disclaimer que incluya la aceptación de todo lo dicho en ese texto a partir del momento en que oprima el botón "SEND".

En los forms, no debe olvidarse de calcular correctamente el espacio en dígitos destinado a que el cliente escriba los datos. Deberá probar el efecto que ocurre cuando se pretende incluir mayor número de dígitos en un área pequeña.

Finalmente, como forma de aplicación de todo lo visto en la descripción precedente, en aquellos sitios que estén enfocados hacia funciones específicas de e-commerce, se deberán extremar las pruebas funcionales destinadas a comprobar en correcto funcionamiento del sistema de compras. Puntos tan importantes como el carrito de compras, la transacción online, la integridad de los canales SSL para el envío de datos encriptados, el envío de una pantalla de recibo y el funcionamiento del mail con la copia de la transacción para registro del comprador, deben ser cuidadosamente probados mediante la única forma posible de averiguarlo: haciendo una auto-compra que permita la evaluación online. Como en general los sistemas de compra online están desarrollados por empresas que brindan este servicio utilizando su propia cuenta de comercio ("merchant account"), la mayoría de las veces la evaluación se limita a comprobar que la página en estudio posea el link que apunte a dicho gateway de entrada en el proveedor del servicio de transacción online.

Pero aún así, existen una serie de detalles que deben ser evaluados de una forma u otra, ya sea en caso de estar operando con sistemas de transacción online de terceras empresas, o mediante un sistema de alta seguridad y merchant account propia.

No se debe olvidar que una cosa tan sencilla como la uniformidad de criterios en la forma de escribir las fechas en los formularios de CGI-BIN puede llevar a confusión en los casos en que no se especifique si se trata de nomenclatura dd/mm/aa o mm/dd/yy. Y es evidente que es difícil reclamar por una compra realizada el 5/11/00 si no se explicita que el 5 es el día y el 11 es el mes.

Detalles a veces pasados por alto, la falta de un verdadero juicio crítico, el desconocimiento de los procesos necesarios para un correcto desarrollo de software, la falta de herramientas para realizar determinado test, pero generalmente la falta de pruebas de carga destinadas a comprobar las condiciones estáticas y dinámicas de un sitio antes de su lanzamiento, pueden llevar a fracasos muy difíciles para una recuperación.

Sugerimos la navegación minuciosa y exhaustiva offline para control de páginas estáticas y de textos, imágenes y links internos en una primera vuelta, y tiempo de latencia medidos en banco de pruebas basado en una red interna.

En una segunda etapa, ya en navegación online, sugerimos comprobar el funcionamiento de los links e imágenes internas en una segunda vuelta, ya que archivos escritos con mayúsculas pero con hipervínculos en minúsculas se abrirán navegando offline, pero no lo harán online. El funcionamiento de los links e imágenes externas, y muy especialmente el funcionamiento de todos los formularios y funciones operadas en forma CGI-BIN deberá ser testeada de la única forma posible: exigiéndolas online. Iguales consideraciones para los motores de búsqueda.

Finalmente, nos permitimos recordar y sugerir que solamente de un verdadero trabajo en equipo entre el departamento de producción de software y el departamento de contenidos, con una cabeza que dirija, regule, supervise, dicte normas, evalúe, y muy especialmente interprete los objetivos del "propietario del sitio" a la luz del target hacia el cual apunta, podrá nacer un producto que realmente cumpla con los objetivos y el diseño original, y donde la necesidad de corrección sea lo suficientemente mínima y necesaria como para no entorpecer los recursos humanos y demorar el proyecto, ni consumir recursos financieros que reclamen partidas adicionales o eventuales quebrantos, ni pensar que con nuevos recursos materiales de soft & hard se podrá arribar a puertos de aguas tranquilas.

Buenos Aires, Argentina