#1 [Teoria] Diseño Web y Estándares Diseño Web y Estándares
Si hay algo en lo que creo, es que la gloria solo dura un instante. Si. Podrá sonar extraño para quien no me conoce, o hasta descabellado por el título de este mensaje, pero está basado en mi experiencia personal.(1)
Formarse y ejercer una profesión como diseñador web en estos momentos no resulta una tarea sencilla, porque como muchos sabrán, vivimos en un lugar del mundo donde en muchas áreas todavía se siguen escatimando recursos y -lamentablemente- por necesidad, no se delegan las tareas a los profesionales que realmente saben del tema. Por ende, es habitual que un diseñador termine aprendiendo programación en Perl o por qué no también en VBScript; puesto que habitualmente tiene que contar con un amplio dominio de PHP, ASP, ASP Net, etc. Y si estamos en esa senda, atravesando alguna de las etapas de aprendizaje, es muy probable que terminemos mareados por el exceso de (des)información.
Con acierto, podemos agregar otros factores: la diversidad de medios para acceder a internet. Desde las tradicionales computadoras personales, a teléfonos celulares, dispositivos de mano, PDAs (Personal Digital Assistants), teletipos, etc. Todos y cada uno de ellos, con sus propias plataformas.
Y sigamos condimentando esta especie de ensalada, con una gran variedad de hierbas, -perdón- navegadores, que se utilizan en la actualidad: Internet Explorer, Mozilla, Netscape, Opera, AOL, ya sean para Mac o PC. ¿Por qué no también incluir un poco de Gecko y sus derivados? O un toquecito de iCab, OmniWeb, Safari Camino, Konkeror específicos para Mac y Linux respectivamente?
Ahora bien, dejando de lado toda analogía culinaria, sabemos que cualquier persona que se haya familiarizado con el uso de algunos programas para diseño, suele hacer lo infaltable: su propio sitio web! O al menos, quién no lo ha intentado? O durante muchos años, quién no ha aprovechado las herramientas que, por defecto traían algunas suites de oficina, como ser por ejemplo, MS Office y su FrontPage Express? ¿Cómo olvidar esas páginas con gifs animados por doquier... mientras veíamos de fondo, esos bitmaps interminables?
Aunque los tiempos hayan cambiado, y los programas también, se sigue aprendiendo en base a prueba y error. Pero se van incorporando también, todos los vicios, inclusive aquellos que heredamos directamente del fabricante de nuestro software favorito (y no hablo precisamente de FrontPage, sino de muchos otros programas muy populares).
Pero eso si! Qué orgullosos nos sentimos cuando vemos nuestro sitio en línea! Contentos, vamos de a poco mejorándolo, en el mejor de los casos. Otras veces, lo olvidamos, y lo abandonamos plagado de enlaces "en construcción" mientras decidimos cómo encarar un nuevo proyecto (sic).
Otros casos: el de muchos estudiantes que, al empezar una carrera relacionada al diseño se lanzan a experimentar con toda su creatividad intacta, publicando sus primeras páginas.
O cuando vemos que muchos profesionales, ya en ejercicio, se encuentran preparados para cubrir las necesidades comunicacionales de una empresa, aunque al mismo tiempo van descubriendo sus propias limitaciones respecto a este medio, ya sea por deficiencias en su formación, como por los avances tecnológicos: la web, sigue a su vez, en constante cambio y ampliado permanentemente el espectro de la comunicación.
Es por ésta razón que se hace necesario un replanteo de la profesión y de la enseñanza de la misma, nos apuntó coreano citando un artículo de la Asociación de Diseñadores Gráficos de Buenos Aires - [Teoria] El Diseño Grafico segun la asociacion de Diseñadores Graficos -). A lo cual yo agregaría que además debemos replantearnos nuestras metas si pretendemos trabajar en este medio: siendo entusiastas, inquietos y emprendedores, tendríamos que investigar e indagar más allá de lo que se ve.
El Volver a la Fuentes:
En otro de los escritos que vimos recientemente publicados (Metodología del Proceso de Diseño: [Teoria] Metodologia del proceso de diseño) Walo nos presenta algunas de las múltiples variables que se deben tener en cuenta, al momento de empezar un proyecto: cómo recabar la información necesaria, los objetivos a plantearse, qué aspectos analizar, y hasta como llegar a la etapa de implementación y testeo del mismo.
Esta metodología supone la preexistencia de un manejo y conocimiento completo de la herramienta más básica y fundamental: El código HTML. Aunque tal vez debería hablar ya de XHTML.
Alguien pensará que soy anticuada, que para eso existen los editores de páginas WYSIWYG (lo que ves es lo que obtienes): para escribir el código mientras nosotros trabajamos cómodamente en un entorno gráfico. Y yo le respondería que si, estos editores escriben solos el código, pero si no conocemos los atributos y las propiedades de los distintos elementos, y las especificaciones en las cuales se basan, no podremos nunca saber qué es lo que nuestro editor preferido está haciendo a nuestras espaldas.
Y entonces... volver a las fuentes...?
¿Cómo? ¿Qué fuente? Si, el código fuente. El que le da sustento a todo lo que gráficamente nos muestran nuestros queridos, modernos y estardarizados (¿?) navegadores (perdón por el chiste de mal gusto).
Sin ese sustento, la página web no existe. Y cuanto más estándar sea el código, mayor será la cantidad de público que podrá acceder a la información que presentemos. Sin éste principio dudo que lleguemos a buen puerto.
El punto de partida no puede ser otro, que las mismas páginas del W3C, o World Wide Web Consortium. Ahí están todas las especificaciones necesarias para redactar un código accesible y sintácticamente correcto, un código actual.
Y todo aquel que se llame a si mismo diseñador web, debería interiorizarse más en las especificaciones y normativas, en los estándares. Actualizarse en cuanto a las nuevas tecnologías, porque los cambios que vemos día a día en la web, se tienen que reflejar en nuestro trabajo también. Y sobre estos temas no pueden tener incidencia ningun tipo de controversias sobre divisiones de tareas o áreas de competencia, entre diseñadores y programadores. Cuando se trata de estar informados, estar actualizados sobre las tendencias actuales, no hablo de leer las noticias de C-Net unicamente, sino de actualizar nuestro código web: La versión actual de HTML, la 4.01, convertida en recomendación en Diciembre del 1997, es la última versión que veremos de éste lenguaje.
El rol del W3C:
El Consortium tiene a su cargo la creación de un código estándar y amplio, que no se limita a un cierto tipo de ordenador, ni sistema operativo. Un código que nos sirve de base para nuestro mensaje, cualquiera que éste sea, y sin importar el medio por el cuál accedemos al mismo. La función del diseñador sería implementarlo. Usarlo.
Owen Briggs no lo pudo haber dicho mejor: "Nuestra tecnología apenas está 'precalentando'. Por eso, el código web es amplio, no se trata solo de como se ven las cosas en una pc o en una Mac..." (Design Rant por Owen Briggs en http://www.thenoodleincident.com). (2)
Finalizaba el año 2001 cuando Briggs redactaba ésto. Así que bien podrán imaginarse como siguió la historia...
Viendo los hechos en retrospectiva, creo que nuestra meta ahora, debería enfocarse a una revisión del código HTML que hayamos escrito, para tomar los elementos que lo conforman, y con ellos construir la estructura que le dará basamento al mensaje que deseamos transmitir. Dichos elementos se deben adaptar a estos tiempos de transición, por medio del uso de un documento acorde, el XHTML.
El XHTML es un lenguaje híbrido que se parece y funciona en forma bastante similar al HTML. Está basado en XML (eXtensible Markup Language), o el meta lenguaje de la web, como le llaman algunos, porque se utiliza para definir otros lenguajes destinados a fines específicos. El XML es utilizado en bases de datos, en trabajos con catálogos, en los feeders tan de moda. Pero también es el lenguaje fundacional para los estándares web de algunos protocolos como ser, el (SVG) Scalable Vector Graphics, el Synchronized Multimedia Integration Language (SMIL), Wireless Markup Language (WML). Aunque todas estas siglas se asemejen más a jeroglíficos que a lenguajes, el XML se podría resumir como texto puro, donde, a diferencia del HTML, somos nosotros quienes definimos los elementos, atributos y propiedades dentro de dicho documento, pudiendo éstos, significar lo que nos parezca apropiado según la tarea que estemos llevando a cabo.
El XHTML:
Los beneficios de utilizarlo, son muchos: Uno de los fundamentales es que son fácilmente trasportables a otros entornos como los que mencioné anteriormente: desde un screen reader a cualquier dispositivo inalámbrico.
Este tipo de documento nos obliga a mantener un orden y una estructura lógica. Pensemos en todo caso, en un medio estrictamente gráfico: si vemos un diario impreso, observaremos un titular, cierto texto a modo de introducción y luego el párrafo que contiene el desarrollo de la noticia. Es esa misma estructura la que se debe mantener en un documento XHTML: los titulares bajo la etiqueta <h1></h1>; los párrafos entre etiquetas <p></p>, etc.
Además de éstas prácticas, que desde ya, deberían ser de uso corriente, tendremos que prestar más atención para escribir todo el código en minúsculas; encerrar todos los valores de los atributos entre comillas; completar obligatoriamente el atributo ALT con el texto correspondiente y un opcional "title" cuando se utilicen imágenes. No porque estemos motivados por la validación de nuestro documento, sino por razones de usabilidad.
Revisar también las normativas en cuanto al cierre de todas las etiquetas, ya que ninguna podrá quedar abierta (el ejemplo más común es el salto de línea o <br> el cual se debe cerrar de esta forma: <br />).
Verificar la correcta escritura del DOCTYPE (DOCTYPE es una declaración del lenguaje SGML o Standard Generalized Markup Language que determina a cual DocumentTyeDefinition o mejor dicho DTD, se ajusta un documento). Cuidar que no se incluyan ningún tipo de prólogo opcional, para que no existan incompatibilidades entre los distintos navegadores. (Notas extraídas de New York Public Library: http://www.nypl.org/styleguide/xhtml/index.html en donde se podrá encontrar mayor información).
Otro de los beneficios de utilizar este formato es la indexación de las páginas en los motores de búsqueda. Un código bien escrito, facilita y agiliza la indexación de todo texto incluido dentro del elemento h1; no solamente en el "title" o en los metatags.
Al tener un documento bien estructurado, su actualización y/o modificación resulta prácticamente una tarea ínfima en tiempo y recursos. Más aún si lo utilizamos conjuntamente con CSS.
En resúmen, lo aconsejable es volver a utilizar los elementos para lo que realmente fueron creados:
Los encabezados (h1/h6) tienen una función, que es definir los títulos y subtítulos.
Los párrafos nos definen los textos y se separan como tales.
Si tenemos varios enlaces agrupados, usemos una lista ordenada o desordenada según corresponda.
Las tablas están destinadas a presentar datos (generalmente numéricos) en forma ordenada, usémoslas para eso y no para crear toda la estructura del sitio. (3)
Para agregarle riqueza visual a nuestras páginas, utilicemos lo que se debe usar: CSS. Una buena combinación de XHTML y CSS no falla al momento de presentar la información de manera accesible pero rica por su atractivo visual.
Alguien me estará odiando a esta altura...ya. ¿Pero por qué no se crean páginas web utilizando éstos estándares? ¿Por qué no se usan las hojas de estilo para darle formato a la información?
Porque si bien es fácil crear un documento XHTML, es mucho más difícil utilizar CSS que una simple "table" para estructurar el contenido de un sitio, cuando tenemos que lidiar con navegadores tan disímiles, para múltiples plataformas y por sobre todo, antiguos u obsoletos. Si elegimos el camino fácil, estamos destinados a quedarnos en el tiempo... y a tener cada vez menor audiencia o usuarios navegando nuestras páginas...
Bien. Estas son solo algunas de la pautas para estructurar el contenido como es debido. Son ideas para comenzar a crear una zona de inicio como la llamo en estos días...
La investigación y el aprendizaje no solo viven en los claustros académicos. Esta infromación está abierta para todos. Yo lo simplificaría en un "tómalo o déjalo."
Carina Kornowski.
[COLOR=dark-blue]Enlaces - Por dónde empezar: )[/color]
http://www.w3.org/
XHTML: recomendación de Enero del 2000 (http://www.w3.org/TR/2000/REC-xml-20001006).
http://www.nypl.org/styleguide/
http://www.webstandards.org/
http://www.digital-web.com/
http://www.zeldman.com/lectures/css/
http://www.stopdesign.com/
http://www.thenoodleincident.com
http://www.alistapart.com
http://www.meyerweb.com
http://www.simplebits.com/
http://www.mezzoblue.com/
http://www.csszengarden.com/
http://www.brainjar.com/
http://www.tantek.com/
http://www.w3schools.com/
http://www.westciv.com
http://www.glish.com/
http://www.bluerobot.com
http://www.saila.com/
http://www.positioniseverything.net/
http://www.theimposter.org/
[COLOR=dark-blue]Otros de interés:[/color]
http://www.hotdesign.com/seybold Un visión divertida del tema.
http://adactio.com/articles/display....S_based_design Al mejor estilo The Matrix . :)
[COLOR=dark-blue]Referencias:[/color]
(1) Hace poco más de dos años, me encontraba por primera vez un Jasc PaintShopPro 7.01. Unos meses más tarde me hice amiga de Adobe Photoshop, y empecé a jugar con "layers" y "masks". Después fue Macromedia Flash, Dreamweaver y Fireworks. Me desvelé con efectos ray of light o matrix... Indagué en los "while loops" de ActionScript, sin dejar de lado ningún "prototype" que me pudiera ser útil para mostrar mi galería fotográfica.
Descubrí quienes eran/son Kris Holmes y Charles Bigelow; Summer Stone, Erik Spiekermann, Martin Majoor y Luc de Groot, entre otros. En esa euforia hasta dibujé a mano varias ligaduras para incluir en mis fuentes favoritas. Armé un juego completo de caracteres para una fuente bitmap, sin descuidar, por cierto, los fondos de escritorio y los íconos para mi pc. Animé copos de nieve en 3D para un Papá Noel que sonreía rodeado de regalitos vectorizados al ritmo de Santa's Coming to Town por Frank Sinatra. Armé proyectos de portfolios personales en todo papelito que tenía a mano, mientras leía cómo se estructura la información para que sea más accesible al usuario. Digitalicé mis portfolios de papel en cuanto formato se me ocurrió, y de un día para otro me encontré buceando entre las páginas de la W3C, tratando de averiguar cuál era el karma de todos los browsers.
¿La gloria dura solo un instante...? Y....si. Es ínfimo el momento de alegría y satisfacción al contemplar un trabajo bien hecho, comparado con las horas de esfuerzo y dedicación invertidas. ¡Pero qué bien se siente! Y valen la pena!
(2)
Design Rant por Owen Briggs: http://www.thenoodleincident.com/tut...ant/index.html
Recomiendo leer todo el artículo.
(3)
Con esto no estoy diciendo que hay que suprimir todas las tablas de un layout, sino que se deben utilizar cuando realmente son necesarias. Una tabla con sus atributos bien definidos, puede estar perfectamente inserta acorde a los estándares y es un hecho que la complejidad de algunos proyectos web, bien ameritan su utilización.
Pero siempre hay que analizar con criterio cuál es el contenido y el mensaje a transmitir: en muchos casos las numerosas etiquetas <font><size><th><td><tr><img> no son necesarias, y bien podrían suprimirse, logrando que un acceso a la información, mucho más rápido, y favoreciendo a todos los públicos.
[COLOR=dark-blue]Anexo: [/color]
[COLOR=dark-blue]Cómo leer las especificaciones del W3C:[/color]
Breve traducción de How to Read W3C Specs de A List Apart
Leer las especificaciones del W3C puede resultar un ejercicio algo frustrante, a menos que conozcamos algunos secretos:
Un manual de reparaciones se escribe con cierta precisión en mente más que como un diálogo informal con el lector. De forma similar, una especificación del W3C se escribe con todo el ritual y la formalidad propia de un juego japonés de Kabuki.
Normativas:
Cuando veamos una sección que incluya dichas palabras, (ésta sección es normativa) nos indica que estamos frente a lo que realmente debemos implementar y bajo que conformidad.
Las secciones informativas, por otra parte, consisten generalmente en ejemplos y explicaciones.
Agente de Usuario:
Se refiere al programa que los usuarios emplearán para tener acceso a la tecnología.
- Para el HTML, eso sería un browser o navegador.
- Para SVG o Scalable Vector Graphics, puede ser un programa de visualización como Batik o un plug-in como el visor SVG del adobe.
RFC;
Pedido de comentarios en sentido literal, pero se refiere a un documento que incorpora un estándar de Internet.
Verbos de Ayuda:
Si una especificación dice que está basada en la RFC2119, los verbos que se utilicen luego, tienen cierto significado formal. Por ejemplo:
- must: significa que la definición es un requerimiento absoluto.
- must not: significa una prohibición directamente.
- should: significa una opción, o sea que se puede implementar cierta característica, pero siempre con motivos suficientes si se opta por no ponerla en ejercicio.
- should not: significa que más vale que tengamos más que buenos motivos para no implementar cierta característica que se está recomendando.
Skim:
Alude a una lectura superficial. Lo cual equivale a que NO es necesario leer y examinar TODA la especificación en forma minuciosa. Si nos encontramos con un área sin etiquetas, aunque parezca una cuestión legal o una charla sobre informática, o ambas cosas, solo bastará un simple vistazo.
Lectura de los BNF:
BNF significa Backus Naur, o Backus Normal Form. Es una manera compacta representar la gramática de los lenguajes de programación, y se usa desde hace rato.
Algunas especificaciones utilizan distintos sabores de BNF, pero todas traducen descripciones inglesas largas a forma simbólica. Por ej. en qué consiste un sandwich: Un sandwich consiste en una rebanada más baja de pan, mostaza o mayonesa; lechuga opcional, una rebanada opcional del tomate; dos a cuatro rebanadas de salame, o de jamón (en cualquier combinación); unas o más rebanadas del queso, y una rebanada del pan superior.
Esto se traduce como:
sandwich::=
lrebanada_baja
[ mostaza | mayonesa ]
¿lechuga? ¿tomate?
[| salame | jamón ] {2,4}
queso+
rebanada_superior
Los componentes de una definición se enumeran en orden, separado por espacios en blanco.
Los items se agrupan con los corchetes, y las opciones dentro de un grupo, son separadas por una barra vertical.
- Si un item tiene un signo de interrogación al final significa: uno o ninguno; si está seguido por un signo más (+), significa que es uno o más de los items.
- Si tiene un asterisco: cero o más.
- Si al final tiene un grupo de números entre corchetes, nos están indicando los límites mínimos y máximos de un item, o posibilidades de que item tenga lugar.
Los paréntesis, o corchetes en forma combinada, se utilizan para agrupar items en definiciones más complejas. A veces un artículo genérico (como "color") se incluye entre < y >, o los items fijos se encierran entre comillas.
Cómo leer un DOCTYPE:
La declaración DOCTYPE que incluyamos en nuestro documento HTML o XHTML le indica al browser o navegador que versión de éstos lenguajes estamos utilizando.
Estas declaraciones se refieren a un Document Type Definition, o el DTD, que define qué combinaciones de elementos son legales en un documento determinado.
Aprender leer un DTD es difícil, pero no es una tarea imposible. Y nos conviene aprenderlo porque el DTD es la última autoridad para saber qué es lo correcto y qué no lo es, en cuanto a la sintaxis de un lenguaje en particular.
Una explicación completa de cómo leer un DTD está más allá del alcance de este artículo, pero se puede encontrar más información en la "Guía Visual Rápida de XML para la World Wide Web" de Elizabeth Castro o en Aprendiendo XML de Erik Ray.
Este es un breve ejemplo de lo que se puede ver en un DTD:
Esto es lo que significaría:
Los elementos relativos al estilo de fuente son < tt >, < i >, y < b >.
Los elementos en línea son elementos relativos al estilo del texto o de la fuente.
Un < div > puede contener un o más < p > o los elementos en línea en cualquier orden.
Un < div > puede tener un atributo opcional con valores para su alineación: izquierda, derecha, o centro.
Idle Past IDL, be Bound by Bindings (atado con ligaduras o enlaces)
Algunas tecnologías XML tales como SVG y SMIL, permiten que el usuario escriba determinados programas para controlar un documento en forma dinámica, de igual forma que con Javascript se puede controlar un documento del HTML.
Sus especificaciones tendrán secciones que describen cómo los scripts funcionan con el Document Object Model. Estas secciones nos muestran las interfaces en IDL, o sea en el Interface Definition Language (Lenguaje para la definición de interfaces).
IDL es una notación genérica para describir las clases de información que un agente de usuario debe hacer accesibles a un ambiente de programación.
IDL no es un lenguaje de programación; es una notación para describir estos interfaces en una manera compacta. Si bien, son informativas, las definiciones de interfaz de IDL no son generalmente lo que estamos buscando.
Lo que estemos buscando probablemente y según el lenguaje de programación utilizado, son los Java bindings o los bindings del ECMAScript.
Estos bindings o links es una forma de llamarle a la lista de objetos, propiedades y métodos disponibles para nuestros scripts.
ECMAScript es la versión estándar de la asociación europea del fabricantes de JavaScript.
Si estamos utilizando otro tipo de lenguajes como ser Perl o Python, tendremos que buscar otras librerías desde Comprehensive Perl Archive Network o en Python XML Special Interest Group.
En resúmen:
- las especificaciones del W3C están escritas para los desarrolladores, y no para los usuarios finales.
- Muchas especificaciones contienen una sección que dice cómo se organizan y cómo deben ser leídas.
- Conocer el vocabulario que utilizan las especificaciones.
- Recordar que no hay que leer cada palabra. Hay que separar las partes que tienen sentido para nosotros.
- Evitar las discusiones de namespaces.
- Aprender a leer BNF: se utilizan en muchos lugares.
- Aprender a leer un DTD para encontrar las respuestas a cualquier duda sobre la sintaxis de un documento.
- Si una tecnología es scriptable, la información está en los bindings.
- Ser paciente y persistente: puede ser sorprendente la cantidad de información que se puede extraer de una especificación de W3C.
Si hay algo en lo que creo, es que la gloria solo dura un instante. Si. Podrá sonar extraño para quien no me conoce, o hasta descabellado por el título de este mensaje, pero está basado en mi experiencia personal.(1)
Formarse y ejercer una profesión como diseñador web en estos momentos no resulta una tarea sencilla, porque como muchos sabrán, vivimos en un lugar del mundo donde en muchas áreas todavía se siguen escatimando recursos y -lamentablemente- por necesidad, no se delegan las tareas a los profesionales que realmente saben del tema. Por ende, es habitual que un diseñador termine aprendiendo programación en Perl o por qué no también en VBScript; puesto que habitualmente tiene que contar con un amplio dominio de PHP, ASP, ASP Net, etc. Y si estamos en esa senda, atravesando alguna de las etapas de aprendizaje, es muy probable que terminemos mareados por el exceso de (des)información.
Con acierto, podemos agregar otros factores: la diversidad de medios para acceder a internet. Desde las tradicionales computadoras personales, a teléfonos celulares, dispositivos de mano, PDAs (Personal Digital Assistants), teletipos, etc. Todos y cada uno de ellos, con sus propias plataformas.
Y sigamos condimentando esta especie de ensalada, con una gran variedad de hierbas, -perdón- navegadores, que se utilizan en la actualidad: Internet Explorer, Mozilla, Netscape, Opera, AOL, ya sean para Mac o PC. ¿Por qué no también incluir un poco de Gecko y sus derivados? O un toquecito de iCab, OmniWeb, Safari Camino, Konkeror específicos para Mac y Linux respectivamente?
Ahora bien, dejando de lado toda analogía culinaria, sabemos que cualquier persona que se haya familiarizado con el uso de algunos programas para diseño, suele hacer lo infaltable: su propio sitio web! O al menos, quién no lo ha intentado? O durante muchos años, quién no ha aprovechado las herramientas que, por defecto traían algunas suites de oficina, como ser por ejemplo, MS Office y su FrontPage Express? ¿Cómo olvidar esas páginas con gifs animados por doquier... mientras veíamos de fondo, esos bitmaps interminables?
Aunque los tiempos hayan cambiado, y los programas también, se sigue aprendiendo en base a prueba y error. Pero se van incorporando también, todos los vicios, inclusive aquellos que heredamos directamente del fabricante de nuestro software favorito (y no hablo precisamente de FrontPage, sino de muchos otros programas muy populares).
Pero eso si! Qué orgullosos nos sentimos cuando vemos nuestro sitio en línea! Contentos, vamos de a poco mejorándolo, en el mejor de los casos. Otras veces, lo olvidamos, y lo abandonamos plagado de enlaces "en construcción" mientras decidimos cómo encarar un nuevo proyecto (sic).
Otros casos: el de muchos estudiantes que, al empezar una carrera relacionada al diseño se lanzan a experimentar con toda su creatividad intacta, publicando sus primeras páginas.
O cuando vemos que muchos profesionales, ya en ejercicio, se encuentran preparados para cubrir las necesidades comunicacionales de una empresa, aunque al mismo tiempo van descubriendo sus propias limitaciones respecto a este medio, ya sea por deficiencias en su formación, como por los avances tecnológicos: la web, sigue a su vez, en constante cambio y ampliado permanentemente el espectro de la comunicación.
Es por ésta razón que se hace necesario un replanteo de la profesión y de la enseñanza de la misma, nos apuntó coreano citando un artículo de la Asociación de Diseñadores Gráficos de Buenos Aires - [Teoria] El Diseño Grafico segun la asociacion de Diseñadores Graficos -). A lo cual yo agregaría que además debemos replantearnos nuestras metas si pretendemos trabajar en este medio: siendo entusiastas, inquietos y emprendedores, tendríamos que investigar e indagar más allá de lo que se ve.
El Volver a la Fuentes:
En otro de los escritos que vimos recientemente publicados (Metodología del Proceso de Diseño: [Teoria] Metodologia del proceso de diseño) Walo nos presenta algunas de las múltiples variables que se deben tener en cuenta, al momento de empezar un proyecto: cómo recabar la información necesaria, los objetivos a plantearse, qué aspectos analizar, y hasta como llegar a la etapa de implementación y testeo del mismo.
Esta metodología supone la preexistencia de un manejo y conocimiento completo de la herramienta más básica y fundamental: El código HTML. Aunque tal vez debería hablar ya de XHTML.
Alguien pensará que soy anticuada, que para eso existen los editores de páginas WYSIWYG (lo que ves es lo que obtienes): para escribir el código mientras nosotros trabajamos cómodamente en un entorno gráfico. Y yo le respondería que si, estos editores escriben solos el código, pero si no conocemos los atributos y las propiedades de los distintos elementos, y las especificaciones en las cuales se basan, no podremos nunca saber qué es lo que nuestro editor preferido está haciendo a nuestras espaldas.
Y entonces... volver a las fuentes...?
¿Cómo? ¿Qué fuente? Si, el código fuente. El que le da sustento a todo lo que gráficamente nos muestran nuestros queridos, modernos y estardarizados (¿?) navegadores (perdón por el chiste de mal gusto).
Sin ese sustento, la página web no existe. Y cuanto más estándar sea el código, mayor será la cantidad de público que podrá acceder a la información que presentemos. Sin éste principio dudo que lleguemos a buen puerto.
El punto de partida no puede ser otro, que las mismas páginas del W3C, o World Wide Web Consortium. Ahí están todas las especificaciones necesarias para redactar un código accesible y sintácticamente correcto, un código actual.
Y todo aquel que se llame a si mismo diseñador web, debería interiorizarse más en las especificaciones y normativas, en los estándares. Actualizarse en cuanto a las nuevas tecnologías, porque los cambios que vemos día a día en la web, se tienen que reflejar en nuestro trabajo también. Y sobre estos temas no pueden tener incidencia ningun tipo de controversias sobre divisiones de tareas o áreas de competencia, entre diseñadores y programadores. Cuando se trata de estar informados, estar actualizados sobre las tendencias actuales, no hablo de leer las noticias de C-Net unicamente, sino de actualizar nuestro código web: La versión actual de HTML, la 4.01, convertida en recomendación en Diciembre del 1997, es la última versión que veremos de éste lenguaje.
El rol del W3C:
El Consortium tiene a su cargo la creación de un código estándar y amplio, que no se limita a un cierto tipo de ordenador, ni sistema operativo. Un código que nos sirve de base para nuestro mensaje, cualquiera que éste sea, y sin importar el medio por el cuál accedemos al mismo. La función del diseñador sería implementarlo. Usarlo.
Owen Briggs no lo pudo haber dicho mejor: "Nuestra tecnología apenas está 'precalentando'. Por eso, el código web es amplio, no se trata solo de como se ven las cosas en una pc o en una Mac..." (Design Rant por Owen Briggs en http://www.thenoodleincident.com). (2)
Finalizaba el año 2001 cuando Briggs redactaba ésto. Así que bien podrán imaginarse como siguió la historia...
Viendo los hechos en retrospectiva, creo que nuestra meta ahora, debería enfocarse a una revisión del código HTML que hayamos escrito, para tomar los elementos que lo conforman, y con ellos construir la estructura que le dará basamento al mensaje que deseamos transmitir. Dichos elementos se deben adaptar a estos tiempos de transición, por medio del uso de un documento acorde, el XHTML.
El XHTML es un lenguaje híbrido que se parece y funciona en forma bastante similar al HTML. Está basado en XML (eXtensible Markup Language), o el meta lenguaje de la web, como le llaman algunos, porque se utiliza para definir otros lenguajes destinados a fines específicos. El XML es utilizado en bases de datos, en trabajos con catálogos, en los feeders tan de moda. Pero también es el lenguaje fundacional para los estándares web de algunos protocolos como ser, el (SVG) Scalable Vector Graphics, el Synchronized Multimedia Integration Language (SMIL), Wireless Markup Language (WML). Aunque todas estas siglas se asemejen más a jeroglíficos que a lenguajes, el XML se podría resumir como texto puro, donde, a diferencia del HTML, somos nosotros quienes definimos los elementos, atributos y propiedades dentro de dicho documento, pudiendo éstos, significar lo que nos parezca apropiado según la tarea que estemos llevando a cabo.
El XHTML:
Los beneficios de utilizarlo, son muchos: Uno de los fundamentales es que son fácilmente trasportables a otros entornos como los que mencioné anteriormente: desde un screen reader a cualquier dispositivo inalámbrico.
Este tipo de documento nos obliga a mantener un orden y una estructura lógica. Pensemos en todo caso, en un medio estrictamente gráfico: si vemos un diario impreso, observaremos un titular, cierto texto a modo de introducción y luego el párrafo que contiene el desarrollo de la noticia. Es esa misma estructura la que se debe mantener en un documento XHTML: los titulares bajo la etiqueta <h1></h1>; los párrafos entre etiquetas <p></p>, etc.
Además de éstas prácticas, que desde ya, deberían ser de uso corriente, tendremos que prestar más atención para escribir todo el código en minúsculas; encerrar todos los valores de los atributos entre comillas; completar obligatoriamente el atributo ALT con el texto correspondiente y un opcional "title" cuando se utilicen imágenes. No porque estemos motivados por la validación de nuestro documento, sino por razones de usabilidad.
Revisar también las normativas en cuanto al cierre de todas las etiquetas, ya que ninguna podrá quedar abierta (el ejemplo más común es el salto de línea o <br> el cual se debe cerrar de esta forma: <br />).
Verificar la correcta escritura del DOCTYPE (DOCTYPE es una declaración del lenguaje SGML o Standard Generalized Markup Language que determina a cual DocumentTyeDefinition o mejor dicho DTD, se ajusta un documento). Cuidar que no se incluyan ningún tipo de prólogo opcional, para que no existan incompatibilidades entre los distintos navegadores. (Notas extraídas de New York Public Library: http://www.nypl.org/styleguide/xhtml/index.html en donde se podrá encontrar mayor información).
Otro de los beneficios de utilizar este formato es la indexación de las páginas en los motores de búsqueda. Un código bien escrito, facilita y agiliza la indexación de todo texto incluido dentro del elemento h1; no solamente en el "title" o en los metatags.
Al tener un documento bien estructurado, su actualización y/o modificación resulta prácticamente una tarea ínfima en tiempo y recursos. Más aún si lo utilizamos conjuntamente con CSS.
En resúmen, lo aconsejable es volver a utilizar los elementos para lo que realmente fueron creados:
Los encabezados (h1/h6) tienen una función, que es definir los títulos y subtítulos.
Los párrafos nos definen los textos y se separan como tales.
Si tenemos varios enlaces agrupados, usemos una lista ordenada o desordenada según corresponda.
Las tablas están destinadas a presentar datos (generalmente numéricos) en forma ordenada, usémoslas para eso y no para crear toda la estructura del sitio. (3)
Para agregarle riqueza visual a nuestras páginas, utilicemos lo que se debe usar: CSS. Una buena combinación de XHTML y CSS no falla al momento de presentar la información de manera accesible pero rica por su atractivo visual.
Alguien me estará odiando a esta altura...ya. ¿Pero por qué no se crean páginas web utilizando éstos estándares? ¿Por qué no se usan las hojas de estilo para darle formato a la información?
Porque si bien es fácil crear un documento XHTML, es mucho más difícil utilizar CSS que una simple "table" para estructurar el contenido de un sitio, cuando tenemos que lidiar con navegadores tan disímiles, para múltiples plataformas y por sobre todo, antiguos u obsoletos. Si elegimos el camino fácil, estamos destinados a quedarnos en el tiempo... y a tener cada vez menor audiencia o usuarios navegando nuestras páginas...
Bien. Estas son solo algunas de la pautas para estructurar el contenido como es debido. Son ideas para comenzar a crear una zona de inicio como la llamo en estos días...
La investigación y el aprendizaje no solo viven en los claustros académicos. Esta infromación está abierta para todos. Yo lo simplificaría en un "tómalo o déjalo."
Carina Kornowski.
[COLOR=dark-blue]Enlaces - Por dónde empezar: )[/color]
http://www.w3.org/
XHTML: recomendación de Enero del 2000 (http://www.w3.org/TR/2000/REC-xml-20001006).
http://www.nypl.org/styleguide/
http://www.webstandards.org/
http://www.digital-web.com/
http://www.zeldman.com/lectures/css/
http://www.stopdesign.com/
http://www.thenoodleincident.com
http://www.alistapart.com
http://www.meyerweb.com
http://www.simplebits.com/
http://www.mezzoblue.com/
http://www.csszengarden.com/
http://www.brainjar.com/
http://www.tantek.com/
http://www.w3schools.com/
http://www.westciv.com
http://www.glish.com/
http://www.bluerobot.com
http://www.saila.com/
http://www.positioniseverything.net/
http://www.theimposter.org/
[COLOR=dark-blue]Otros de interés:[/color]
http://www.hotdesign.com/seybold Un visión divertida del tema.
http://adactio.com/articles/display....S_based_design Al mejor estilo The Matrix . :)
[COLOR=dark-blue]Referencias:[/color]
(1) Hace poco más de dos años, me encontraba por primera vez un Jasc PaintShopPro 7.01. Unos meses más tarde me hice amiga de Adobe Photoshop, y empecé a jugar con "layers" y "masks". Después fue Macromedia Flash, Dreamweaver y Fireworks. Me desvelé con efectos ray of light o matrix... Indagué en los "while loops" de ActionScript, sin dejar de lado ningún "prototype" que me pudiera ser útil para mostrar mi galería fotográfica.
Descubrí quienes eran/son Kris Holmes y Charles Bigelow; Summer Stone, Erik Spiekermann, Martin Majoor y Luc de Groot, entre otros. En esa euforia hasta dibujé a mano varias ligaduras para incluir en mis fuentes favoritas. Armé un juego completo de caracteres para una fuente bitmap, sin descuidar, por cierto, los fondos de escritorio y los íconos para mi pc. Animé copos de nieve en 3D para un Papá Noel que sonreía rodeado de regalitos vectorizados al ritmo de Santa's Coming to Town por Frank Sinatra. Armé proyectos de portfolios personales en todo papelito que tenía a mano, mientras leía cómo se estructura la información para que sea más accesible al usuario. Digitalicé mis portfolios de papel en cuanto formato se me ocurrió, y de un día para otro me encontré buceando entre las páginas de la W3C, tratando de averiguar cuál era el karma de todos los browsers.
¿La gloria dura solo un instante...? Y....si. Es ínfimo el momento de alegría y satisfacción al contemplar un trabajo bien hecho, comparado con las horas de esfuerzo y dedicación invertidas. ¡Pero qué bien se siente! Y valen la pena!
(2)
Design Rant por Owen Briggs: http://www.thenoodleincident.com/tut...ant/index.html
Recomiendo leer todo el artículo.
(3)
Con esto no estoy diciendo que hay que suprimir todas las tablas de un layout, sino que se deben utilizar cuando realmente son necesarias. Una tabla con sus atributos bien definidos, puede estar perfectamente inserta acorde a los estándares y es un hecho que la complejidad de algunos proyectos web, bien ameritan su utilización.
Pero siempre hay que analizar con criterio cuál es el contenido y el mensaje a transmitir: en muchos casos las numerosas etiquetas <font><size><th><td><tr><img> no son necesarias, y bien podrían suprimirse, logrando que un acceso a la información, mucho más rápido, y favoreciendo a todos los públicos.
[COLOR=dark-blue]Anexo: [/color]
[COLOR=dark-blue]Cómo leer las especificaciones del W3C:[/color]
Breve traducción de How to Read W3C Specs de A List Apart
Leer las especificaciones del W3C puede resultar un ejercicio algo frustrante, a menos que conozcamos algunos secretos:
Un manual de reparaciones se escribe con cierta precisión en mente más que como un diálogo informal con el lector. De forma similar, una especificación del W3C se escribe con todo el ritual y la formalidad propia de un juego japonés de Kabuki.
Normativas:
Cuando veamos una sección que incluya dichas palabras, (ésta sección es normativa) nos indica que estamos frente a lo que realmente debemos implementar y bajo que conformidad.
Las secciones informativas, por otra parte, consisten generalmente en ejemplos y explicaciones.
Agente de Usuario:
Se refiere al programa que los usuarios emplearán para tener acceso a la tecnología.
- Para el HTML, eso sería un browser o navegador.
- Para SVG o Scalable Vector Graphics, puede ser un programa de visualización como Batik o un plug-in como el visor SVG del adobe.
RFC;
Pedido de comentarios en sentido literal, pero se refiere a un documento que incorpora un estándar de Internet.
Verbos de Ayuda:
Si una especificación dice que está basada en la RFC2119, los verbos que se utilicen luego, tienen cierto significado formal. Por ejemplo:
- must: significa que la definición es un requerimiento absoluto.
- must not: significa una prohibición directamente.
- should: significa una opción, o sea que se puede implementar cierta característica, pero siempre con motivos suficientes si se opta por no ponerla en ejercicio.
- should not: significa que más vale que tengamos más que buenos motivos para no implementar cierta característica que se está recomendando.
Skim:
Alude a una lectura superficial. Lo cual equivale a que NO es necesario leer y examinar TODA la especificación en forma minuciosa. Si nos encontramos con un área sin etiquetas, aunque parezca una cuestión legal o una charla sobre informática, o ambas cosas, solo bastará un simple vistazo.
Lectura de los BNF:
BNF significa Backus Naur, o Backus Normal Form. Es una manera compacta representar la gramática de los lenguajes de programación, y se usa desde hace rato.
Algunas especificaciones utilizan distintos sabores de BNF, pero todas traducen descripciones inglesas largas a forma simbólica. Por ej. en qué consiste un sandwich: Un sandwich consiste en una rebanada más baja de pan, mostaza o mayonesa; lechuga opcional, una rebanada opcional del tomate; dos a cuatro rebanadas de salame, o de jamón (en cualquier combinación); unas o más rebanadas del queso, y una rebanada del pan superior.
Esto se traduce como:
sandwich::=
lrebanada_baja
[ mostaza | mayonesa ]
¿lechuga? ¿tomate?
[| salame | jamón ] {2,4}
queso+
rebanada_superior
Los componentes de una definición se enumeran en orden, separado por espacios en blanco.
Los items se agrupan con los corchetes, y las opciones dentro de un grupo, son separadas por una barra vertical.
- Si un item tiene un signo de interrogación al final significa: uno o ninguno; si está seguido por un signo más (+), significa que es uno o más de los items.
- Si tiene un asterisco: cero o más.
- Si al final tiene un grupo de números entre corchetes, nos están indicando los límites mínimos y máximos de un item, o posibilidades de que item tenga lugar.
Los paréntesis, o corchetes en forma combinada, se utilizan para agrupar items en definiciones más complejas. A veces un artículo genérico (como "color") se incluye entre < y >, o los items fijos se encierran entre comillas.
Cómo leer un DOCTYPE:
La declaración DOCTYPE que incluyamos en nuestro documento HTML o XHTML le indica al browser o navegador que versión de éstos lenguajes estamos utilizando.
Estas declaraciones se refieren a un Document Type Definition, o el DTD, que define qué combinaciones de elementos son legales en un documento determinado.
Aprender leer un DTD es difícil, pero no es una tarea imposible. Y nos conviene aprenderlo porque el DTD es la última autoridad para saber qué es lo correcto y qué no lo es, en cuanto a la sintaxis de un lenguaje en particular.
Una explicación completa de cómo leer un DTD está más allá del alcance de este artículo, pero se puede encontrar más información en la "Guía Visual Rápida de XML para la World Wide Web" de Elizabeth Castro o en Aprendiendo XML de Erik Ray.
Este es un breve ejemplo de lo que se puede ver en un DTD:
Código:
<!ENTITY %fontstyle "(tt | i | b)"> <!ENTITY %inline "(#PCDATA | %fontstyle;)"> <!ELEMENT div (p | %inline;)+> <!ATTLIST div align (left | right | center) #IMPLIED>
Los elementos relativos al estilo de fuente son < tt >, < i >, y < b >.
Los elementos en línea son elementos relativos al estilo del texto o de la fuente.
Un < div > puede contener un o más < p > o los elementos en línea en cualquier orden.
Un < div > puede tener un atributo opcional con valores para su alineación: izquierda, derecha, o centro.
Idle Past IDL, be Bound by Bindings (atado con ligaduras o enlaces)
Algunas tecnologías XML tales como SVG y SMIL, permiten que el usuario escriba determinados programas para controlar un documento en forma dinámica, de igual forma que con Javascript se puede controlar un documento del HTML.
Sus especificaciones tendrán secciones que describen cómo los scripts funcionan con el Document Object Model. Estas secciones nos muestran las interfaces en IDL, o sea en el Interface Definition Language (Lenguaje para la definición de interfaces).
IDL es una notación genérica para describir las clases de información que un agente de usuario debe hacer accesibles a un ambiente de programación.
IDL no es un lenguaje de programación; es una notación para describir estos interfaces en una manera compacta. Si bien, son informativas, las definiciones de interfaz de IDL no son generalmente lo que estamos buscando.
Lo que estemos buscando probablemente y según el lenguaje de programación utilizado, son los Java bindings o los bindings del ECMAScript.
Estos bindings o links es una forma de llamarle a la lista de objetos, propiedades y métodos disponibles para nuestros scripts.
ECMAScript es la versión estándar de la asociación europea del fabricantes de JavaScript.
Si estamos utilizando otro tipo de lenguajes como ser Perl o Python, tendremos que buscar otras librerías desde Comprehensive Perl Archive Network o en Python XML Special Interest Group.
En resúmen:
- las especificaciones del W3C están escritas para los desarrolladores, y no para los usuarios finales.
- Muchas especificaciones contienen una sección que dice cómo se organizan y cómo deben ser leídas.
- Conocer el vocabulario que utilizan las especificaciones.
- Recordar que no hay que leer cada palabra. Hay que separar las partes que tienen sentido para nosotros.
- Evitar las discusiones de namespaces.
- Aprender a leer BNF: se utilizan en muchos lugares.
- Aprender a leer un DTD para encontrar las respuestas a cualquier duda sobre la sintaxis de un documento.
- Si una tecnología es scriptable, la información está en los bindings.
- Ser paciente y persistente: puede ser sorprendente la cantidad de información que se puede extraer de una especificación de W3C.
0
y validen por sí mismos un par de páginas que armé! 
