Portada de TV y Novelas

Lo importante tiene que aparecer en la portada. Pero, ¿qué es lo importante? ¿quién lo determina? Quizá a muchos nos cruza por la cabeza la palabra editor y más aún, podríamos determinar que “él decide, él dirige, y punto”.

Si hacemos la analogía con la Web, la portada vendría siendo la página de inicio. ¿Cuáles son las respuestas a las mismas preguntas? El editor o webmaster sería quien determina qué, en qué orden y dónde van las cosas ¿no? Sin embargo, la Web es una de las entidades donde el poder del usuario final tiene más peso para lograr el éxito ¿o no?

Supongamos que el webmaster es en sí el “diseñador web”: el que se encarga no sólo del mantenimiento sino que ha participado tiempo atrás, tanto en la estructura como en el layout. Este caso es fácilmente visible en freelancing o en trabajos donde un equipo pequeño (incluso de una o dos personas) se encarga de un sitio completo.

Pues bien, la premisa del “lado del diseñador” sería “poseo los conocimientos para determinar cómo indentificar la estructura del sitio y la interfaz de este”; ergo, “aquí está el sitio propuesto, úsese”. Sin embargo, existe una contraparte: los stakeholders o las personas interesadas (en el sitio). No estamos hablando del usuario final. Entre estas personas puede estar quien encarga el sitio (contratista), el jefe, un comité que determina qué información se estará presentando, etc. Lo “sabroso” se da cuando la mente (y el ego, por qué no) del diseñador se encuentra con la de los stakeholders para determinar, entre otras cosas, qué incluye y cómo debe ser la página de inicio, la “gran carta de presentación”.

En ese cruce de “aires”, cual formación de tornado, suele darse un “Síndrome de portada TV y Novelas” en el index o página de inicio, el cual corrompe terriblemente la posible propuesta óptima de interfaz web por parte del diseñador. Todo es importante y todo debe resaltar. Claro, las opiniones son muy sesgadas dependiendo del stakeholder en cuestión. Justo ahí es donde entra el grado de influencia de cada uno de ellos; sin embargo, todos quieren tener visible el nicho de información de su interés.

La “homepage TV y Novelas”, le pone al usuario todo a la mano, eso debe ser bueno. Se pueden encontrar banners animados en flash y muchos botones o imágenes por todas partes, textos de gran tamaño, menús desplegables con muchas pero muchas opciones, más de 5 logotipos (por eso de mostrar que el sitio es importante), etc. 

El ying-yang de este asunto puede describirse así: el diseñador web no preparó la estructura (navegacional y visual) del sitio “a prueba de balas” y tampoco se preocupó por sensibilizar a los stakeholders hacia una cultura de la usabilidad y fucionalidad (¿qué queremos con el sitio? ¿para qué servirá?); por otro lado, las personas interesadas sí quitan autoridad al diseñador (aunque se les explique), debido a que lo “importante” es lo importante y tiene que estar en el index, cuanto más opciones, mejor. No se trata de armar “pleito”, ni de ver quién tiene la razón, sino de darse cuenta que un sitio web va más allá de “presentar información”, porque en la mayoría de las veces están ahí para usarse.

¿Y a qué lleva el último punto? La respuesta es simple: cuando los usuarios usan el sitio (valga la redundancia), se topan con una página de inicio saturada, con demasiada información, muchas opciones para seguir navegando y que pobremente responde a sus necesidades. Después, cuando llega la retroalimentación, sobretodo en esas situaciones donde se apremia “la calidad en el servicio”, los stakeholders se dan cuenta que la página de inicio y todo el sitio, están mal.  Como parte de este síndrome entra su desesperación por no quedar mal y demostrar que sí hay aptitud, que se tiene un sitio web bueno, usable y relevante. Es posible que en este punto se recurra de nuevo al diseñador para que “corrija” tales desperfectos.

El síndrome puede evitarse, pero requiere de la participación de los stakeholders y que sepan hasta dónde llega su autoridad, dejando lo pertinente al diseñador web, que en teoría es el experto y sabe lo que conviene pensando en los usuarios del sitio. Lo complicado está que se involucran aspectos emocionales (en particular de egocentrismo) tanto en el diseñador como en las personas interesadas, por lo que “sanar” es más difícil de lo que parece.

El diseñador para ponerse frío, hay que reconocerlo, debe hacer su chamba, documentar en la medida de lo posible (wireframes y blueprints, esquemas y diagramas, todo lo válido para comunicar por qué se hacen las cosas) y ser claro ante los stakeholders sobre lo que se pensó, lo que se tiene, lo que puede ser y lo que se podría hacer. 

¿Complicado o díficil? Sí. Pero es parte del show ¿o no?

Con respecto a la indentación, el primer pensamiento que he notado en chavos que aprenden XHTML es Who cares!! Sin embargo, no importa si es XML, CSS, C++, JavaScript o lo que sea, indentar es definitivamente una buena práctica. En mi opinión:

1. Te permite identificar fácilmente la estructura del código: bloques de procesos y sus sub-procesos internos o estructuración semántica del contenido (en XML o XHTML); lo cual,
2. fomenta una construcción mental ordenada de lo que estás codificando/escribiendo. Este orden te permite extraer y concentrarte en solo un bloque particular, a groso modo si es el proceso grande o detallado si es un sub-proceso.
3. Ayuda a descansar al lector en el proceso cognitivo de lectura-entendimiento (cuando no es el autor quien lee).

Con respecto a al punto 3, y esto de descansar o descargar cognitivamente al lector (usuario), pues ¿qué no es válido que exista un “diseño” en el código mismo? Diseñadores: si nos preocupamos en diseño editorial y de información por dar una estructura jerárquica a los textos, ¿por qué no hacerlo en códigos?

Quizá no haya tanta importancia entre

<head>

</head>

<body>

<body>

con

<head>

  </head>

  <body>

  </body>

Pero cuando las cosas comienzan a aumentar como en

<head>

     <title></title>

     <meta ...>

     <meta ...>

     <link ...>

     <script>

         bla bla bla...

     </script>

</head>

<body>

  <div id="hdr">

    <ul id="menu-principal">

        <li></li>

        <li></li>

        <li></li>

    </ul>

  </div>
  <div id="content">

    <div id="col-izq">

        <p> ... </p> 

        <p> ... </p> 

    </div>

    <div id="col-der">

        <p> ... </p> 

        <p> ... </p> 

    </div>

    </div>

    <div id="ftr">

        <p> ... </p>

        <p> ... </p>

    </div>

  </div>

</body>

pues no hay duda que indentar nos da una buena “ayudadita”.

Ya en lenguajes completos (de aplicaciones) o de guiones (scripts), esto de la indentación es un must, sobretodo con esto de que no necesariamente seremos nosotros quienes lean nuestro código. Nunca está demás dejar la sangría necesaria, al menos para marcar cuándo empieza y termina un bloque de código y así:

• diferenciar entre los grandes chunks de información (clases, métodos y funciones),
• marcar bien los procesos repetitivos (ciclos for, while y repeat until), o bien, 
• reconocer qué decisiones se tomarán a partir de ciertas condiciones (por ejemplo en if-then, switch-case o “ifs” anidados).

También está el asunto de estandarizar el cómo codificamos. Es algo bueno de aplicar en la mayor medida de lo posible por la misma razón del párrafo anterior, aunque también nos puede beneficiar a nosotros mismos: en algunos casos si dejamos las cosas enfríar un rato para luego retomar el trabajo, puede ser que ya ni nos acordemos qué es lo que escribimos o dónde nos queamos.

Por ejemplo, si tenemos muchas especificaciones en CSS, pues un

/*Footer*/

nos ayudaría a identificar que de ahí para abajo (hasta otra marca) son cosas que tienen que ver con el contenedor footer. Se que parece tonto, pero en mi caso cuando tengo una hoja de estilo con muchas cosas, ya ni ganas me dan de leerla.

Se ve con mayor claridad este asunto en las rutinas de programación. Por ejemplo, una cabecera ayuda a recordar qué estamos haciendo, o bien, si alguien más nos lee, al menos puede tener una idea de qué hay en el archivo aunque no lea detalladamente nuestro código.

/*****************************************************************

  Nombre: imprime_datos_usuario
  Fecha de creacion: 26-julio-2008
  Autor: Omar Sosa Tzec
  Entradas: strNombreUsr - Nombre del usuario.
            strDireccionUsr - Direccion del usuario.
  Salidas: intStatus - Verificador de que se imprimieron bien los datos en documento.
          1 si estuvo todo bien. 0 si hubo algun error.
  Descripcion: Recibe datos del usuario y entonces verifica que tienen validez consultando la tabla de usuarios validos y de ahi incrustarlos en el documento-mensaje de salida con la variable de estatus.
/*****************************************************************/

También en el manejo de variables, muchas veces resulta conveniente empezar éstas con algún identificador que de antemano nos diga de qué tipo es: un int para las variables enteras, un str para las cadenas, un flt para las flotantes o punto decimal, etc.

A partir de este punto, podemos hacer combinaciones de mayúsculas con minúsculas para nombrar las variables. Por ejemplo, fltResultadoDivision. Para otras palabras reservadas también podemos definir nuestros estándares. Por ejemplo, Persona para la clase persona y Pepe para nombrar un objeto de esta clase.

En CSS por otro lado, si son cosas que tienen que ver con un ID llamado header, por ejemplo, un estándar práctico es quizá ponerle fondo-hdr.gif a su imagen de fondo o en las especificaciones poner .deocor-hdr para llamar a una clase que aplica sólo en este ID.

Sí, ya se: puede ser un verdadero fastidio estar haciendo esto. Tampoco hay que exagerar, y dependiendo de qué estemos haciendo, tomar lo que se nos acomode mejor. Pero sin duda, un poco de estandarización y limpieza de código cae bien, sobretodo cuando se trabaja en equipo.