Posts Tagged ‘css’

La cuestión de dar clases

Hace ya muchos años que doy clases y hace algunos que me considero profesor (al menos tanto como me considero diseñador, que no es mucho pero es algo). Hoy me preguntaba qué consejos le daría a una persona que está empezando a dar clases.

Por qué dar clases

Cada cual tendrá sus motivos por los cuales dedica todo o parte de su tiempo a la enseñanza: yo doy clases porque me gusta. Después de varios años comprendí que en pocas situaciones me siento tan feliz, completo, útil y trascendental como cuando al frente de un aula o taller.

Como diseñadores —sea por necesidad o debido al envión mismo que va tomando la práctica profesional— estamos acostumbrados a realizar algunos proyectos que carecen de trascendencia: diseñar un catálogo X, el sitio web institucional para la empresa Y, las tarjetas personales del licenciado Z. Hay proyectos que son interesantes —y entonces uno se siente un engranaje útil de la sociedad— y otros que no lo son, y entonces uno está ahí trayendo al mundo más objetos innecesarios.

Dar clases es siempre útil a la sociedad (hay excepciones: uno puede enseñar a construir bombas nucleares y entonces qué sé yo). En fin, la educación nunca está de más, diríamos que todo lo contrario: falta y hace falta. Enseñar es hermoso porque aprender es hermoso. Acompañar a otra persona en su proceso de aprendizaje, contarle lo poco que uno sabe, guardarse algunas respuestas para preservar su derecho al descubrimiento y eventualmente estar presente cuando lo descubren, ayudarla a pensar por su cuenta: es un lujo. Me siento un tipo muy afortunado al ser remunerado por tan lindo trabajo. Lo digo con toda sinceridad.

Algunos (pocos) tips

Con el correr del tiempo fui dándome cuenta de ciertas cuestiones que son importantes a la hora de dar clases. Algunas podrán sonar obvias y otras no tanto. Trataré de hacer hincapié en las que siento más personales, menos dichas. Lo primero que voy a decir es lo siguiente: no escuchen a los pedagogos. Eso: no escuchen, lean, presten demasiada atención a los dichos de pedagogos y afines. No tengo argumento válido al respecto —y estoy seguro que habrá excepciones—, pero la experiencia y las charlas compartidas con otros docentes me han dado la razón. No soy el único con esta sensación. Hay algo raro, poco feliz, que ocurre con la recursividad de la tarea del que intenta únicamente enseñar a enseñar, que no funciona. Al menos les diría que no confíen en los pedagogos que, al mismo tiempo, no sean docentes en otra materia de estudio. Diferente es un docente que ha decidido estudiar pedagogía para ahondar en los misteriosos mecanismos que se activan al momento del aprendizaje, pero la pedagogía por sí sola, ocupándose del meta-problema pero nunca del problema, no.

Se sobreentiende, supongo, que este artículo es un conjunto de opiniones más o menos fundadas, en base a mi experiencia personal. No pretendo hacer de esto una serie de consejos nunca vistos, ni originales, ni mucho menos verdaderos. Por otra parte, yo suelo dar clases en el ámbito terciario y universitario: lo más probable es que haya que pensar alternativas para diferentes niveles: como el primario y secundario.

El habla

La principal herramienta con que contamos es la voz. Es imprescindible hablar claro, más despacio que lo habitual, con potencia (sin romperse la voz: conviene educarla para una correcta impostación, el punch viene del diafragma, no de la garganta… la panza, digamos: las tripas). Evitar la monotonía en el tono (los estudiantes se duermen), conviene actuar un poco, inventarse y creerse un personaje. Tratar de utilizar el vocabulario más preciso, pertinente y técnico posible. Permitirse el silencio y pensar antes de hablar está muy bien; cuesta, porque uno está acostumbrado a pensar en el contenido de aquello que dice, pero no tanto en la forma: en una clase ambas tienen la misma importancia.

Yo encontré que me es útil, además, romper el hielo de vez en cuando con chistes o vocabulario coloquial. Decir alguna estupidez. No importa la época en que vivimos, o si tenemos un tatuaje en medio de la frente: quienes toman un curso generalmente se sobresaltan cuando escuchan al que en ese momento juega el rol docente decir el explorer es una mierda, esta documentación no se entiende un carajo, etc. Es poco protocolar, puede sonar estúpido, pero sirve para recuperar la atención de quienes puedan estar pegándose un embole de aquellos.

Estructura

En lo posible trato de estructurar la clase. Aprendí que crearse pequeños ritos ayuda a organizar el tiempo. Es conveniente tener un par más, pero absolutamente imprescindible tener un rito de apertura y uno de cierre. Esto hace las veces de <clase> bla bla bla </clase>, quienes sepan algo de HTML entenderán la metáfora. Sentido de conclusión, dirán los músicos. Es importante que quienes acuden a una clase puedan percibir cuándo empieza y cuándo termina. Es, en parte, la razón por la que algunos profesores obligaban a sus alumnos a ponerse de pie al ingresar al aula: la joda terminó, ahora empieza la clase (obviamente, con connotaciones extra que en lo personal no me interesan: autoridad, superioridad, etc).

Algunos de mis ritos incluyen:

  • Un saludo inicial, absolutamente explícito. ¿Cómo andan? ¿Qué hicieron? ¿Algo interesante que debiéramos saber? ¿Alguna película, obra de teatro, muestra en algún museo? Mis clases suelen ser de diseño, o tener cierta relación (tecnología para diseñadores, desarrollo web para diseñadores), por lo que estas preguntas no están fuera de tema y enriquecen a todos quienes estamos presentes.
  • Una breve reseña, a modo de recordatorio, de lo hecho la clase inmediatamente anterior. Esto, muy breve. Y la posibilidad de que se hagan preguntas al respecto.
  • Un brevísimo índice, describiendo los títulos que se verán en el día.
  • La clase en sí.
  • Para dar fin a la clase: una reseña de los temas vistos (que tiende a parecerse al índice inicial, pero es apenas más descriptiva e incluye las cuestiones que no se habían planificado y fueron surgiendo durante la clase).

Planificación

Es importante establecer la planificación clase a clase. La primera vuelta no suele ser muy fidedigna: se pretende que el docente planifique necesariamente antes de saber cuánto va a rendir cada encuentro. Quiero decir: es muy probable que luego uno se dé cuenta que las clases quedan cortas en relación a todo lo que se había pensado de antemano o todo lo contrario, que sobra tiempo.

Ahora bien, si durante la primera vuelta (por ejemplo: el primer cuatrimestre que dictamos un curso específico) vamos anotando prolijamente lo que en efecto se hizo cada clase, tendremos un programa y un plan clase-a-clase súper ajustado y realista, que evidentemente podrá ser mejorado para las iteraciones siguientes, pero donde tendremos muy claro el rendimiento de cada encuentro.

Emergentes (o lo que no puede ser planificado)

Gran parte de lo que ocurre en una clase surge ahí mismo: es esperable que así sea. Es difícil, cuesta acostumbrarse, pero tanto mejor si se es capaz de estar atento a estos emergentes y ser lo suficientemente flexible para aprovecharlos como la verdadera oportunidad que significan, en vez de descartarlos de cuajo como una mera disgreción.

Los emergentes aparecen en diversas formas (like the Devil, they wear many disguises): puede ser una idea nuestra, una conexión que hacemos nosotros, consciente o inconscientemente, al momento mismo de dar la clase; puede ser una pregunta de un estudiante; un comentario, una charla que oímos al pasar; un chiste enunciado por alguno de los presentes. Siempre y cuando sea pertinente, aprovechar estos emergentes es crucial para hacer de la clase un momento dinámico, pero también único. De otra forma nos aburriremos nosotros por la necesaria repetición que implica dar un curso muchas veces y entonces aburriremos a los alumnos.

Be good

A nadie le gusta que se lo trate mal (al menos no conscientemente, no en una clase, no cuando se es estudiante). Hay cursos que salen mejor, otros peor. Hay grupos con los que se establece un vínculo productivo enseguida, otros que significan un desafío más exigente. Es muy fácil caer en la idea de creer que el alumno no entiende nada y qué barbaridad, el twitter, facebook, la juventud, etc. Pero cuando dentro del aula alguien no entiende, el mayor responsable es uno. A veces es difícil y uno se exaspera porque también es humano, pero es necesario tratar siempre con respeto y cariño al prójimo: el que se está explicando mal es uno.

Es que elegimos esta profesión no para enseñarle a los que ya saben, o a quienes podrían aprender solos; sino justamente a quienes necesitan este espacio. Elegimos dar clases, como diría Kennedy, not because it’s easy, but because it’s hard.

Explorer go home

Quienes trabajamos en el desarrollo de sitios web sabemos que el Internet Explorer, de Microsoft, es de lo peor. Lo sabemos, no por nuestro fanatismo geek, los numerosos artículos que versan sobre sus vulnerabilidades en materia de seguridad, o por boca de terceros, sino porque sufrimos diariamente sus caprichos y su incorrecta interpretación de código HTML y CSS.

Cuando terminamos de escribir el código y los estilos de un sitio, cuidando que todo esté acorde a los estándares dictados por la W3C, y pasamos a testearlo en diferentes navegadores, vemos que la mayoría muestra las páginas de la forma esperada… la mayoría, salvo el Internet Explorer. De ahí que estamos obligados a introducir hacks —en muchos casos incluso código no estándar— para reparar el problema. Este fenómeno suma horas, complicaciones inesperadas, incertidumbre y stress a nuestra tarea de desarrollo.

Una posible solución a largo plazo, es procurar que los usuarios elijan otros navegadores y dejen de utilizar IE (algo que está ocurriendo: las estadísticas de los últimos años muestran cómo viene perdiendo terreno el que alguna vez fue el navegador más utilizado).

Educar al soberano:

Dejar de incluir hacks en los sitios que desarrollamos sería una buena táctica; algo así como una guerrilla de insurrectos desarrolladores web —aunque convengamos que sería complicado explicarle a nuestro cliente que ve su sitio destartalado porque está utilizando Internet Explorer, que es el peor navegador, y entonces debiera cambiarlo y utilizar Firefox, o Chrome o Safari, lo mismo que los demás visitantes del sitio—. Eso es imposible. El cliente quiere que su sitio se vea perfecto en todos los principales navegadores, especialmente en el bendito Explorer.

Estos pocos días que transcurrieron desde que puse en marcha mi blog personal me han enseñado mucho. Ayer, por ejemplo, pensé que tener un sitio web personal implica hacer lo que se me de la gana. Decidí que no agregaría hacks para solucionar los errores de interpretación de IE, y que aportaría mi granito de arena para explicarle a los navegantes usuarios de Explorer que les convenía utilizar otros navegadores. Decidí incluir un cartel —visible únicamente para usuarios de IE— que los alerte e invite a probar otras alternativas.

Hay muchas maneras de presentar contenido únicamente a Internet Explorer. Voy a explicar a continuación cómo está resuelto en el caso de este sitio web en particular.

A modo de receta de cocina, diré que haremos uso de:

  • los comentarios condicionales de IE.
  • un poco de javascript no intrusivo.
  • css a gusto para condimentar.

Comentarios condicionales:

Quizás porque la gente de Mircosoft sabe que su navegador deja mucho que desear, inventaron una forma fácil para que los desarrolladores podamos escribir código que sólo el IE pueda ver; lo hicieron en la forma de comentarios de HTML, pero con una estructura estándar que el IE leerá.

Haciendo uso de esta posibilidad, podemos agregar un archivo JavaScript externo, que sólo IE verá. Escribiendo el siguiente código dentro de la etiqueta head:

<!--[if IE]>
    <script type="text/javascript" src="ruta_al_archivo_javascript.js"></script>
<![endif]-->

Los demás navegadores verán eso como parte de un comentario de HTML, y no cargarán el JS externo.

Un poco de JS no intrusivo:

A continuación, utilicé un poco de JavaScript para escribir contenido en el HTML. ¿No podría haber escrito el código HTML directamente dentro de la etiqueta body, utilizando los comentarios condicionales propios de IE? Sí, lo podría haber hecho, pero preferí utilizar JS porque no quería ensuciar el código HTML (ni siquiera con un “comentario”) con todo este asunto. Cada cual podrá sopesar qué le conviene, según el caso.

El código JS será algo así:

// definir la funcion escribirCartelIE:
function escribirCartelIE() {
    // chequea que funcione el control del DOM desde JS:
    if (!document.getElementsByTagName){
        return;
    }
    // crear una referencia al body:
    var body_element = document.body;
    // modificar el contenido del body, agregándole un poco de HTML al principio:
    body_element.innerHTML = '<div id="cartel_ie"><p>Ups! Est&amp;aacute;s utilizando Internet Explorer.</p><p>El <strong>Microsoft Internet Explorer</strong> es un navegador web inseguro, inc&amp;oacute;modo y cuya habilidad para mostrar correctamente las p&amp;aacute;ginas web deja mucho que desear. Por fortuna, no es el &amp;uacute;nico navegador que existe en el mercado. Te recomiendo que pruebes alguno de los siguientes navegadores:</p><ul><li><a href="http://www.mozilla.com">Mozilla Firefox</a></li><li><a href="http://www.google.com/chrome">Google Chrome</a></li><li><a href="http://www.apple.com/safari/">Apple Safari</a></li><li><a href="http://www.opera.com">Opera</a></li></ul></div>' + body_element.innerHTML;
}
// hacer todo cuando se cargue el HTML:
window.onload = escribirCartelIE;

Desde ya, el mensaje puede ser otro. Estoy seguro de que tendrán más imaginación que yo a la hora de redactar el texto.

Fíjense que no incluí código JS en el html. Recuerden que es siempre conveniente mantener separado el contenido (HTML), de la presentación (CSS) y del comportamiento (JS).

CSS a gusto:

Cuando el IE termine de cargar la página, ejecutará la función escribirCartelIE, que modificará el contenido del HTML. A partir de ese momento, el HTML literalmente tendrá nuevos elementos: un div con id cartel_ie y su contenido.

Las órdenes de cómo deben presentarse estos elementos, pueden estar junto con los demás selectores, en el archivo CSS que se esté usando. Esto no afecta al resto del contenido del CSS. Los navegadores que no tengan ese elemento en el HTML, no aplicarán esas órdenes del CSS.

Aquí, a modo de ejemplo, el código CSS que se está utilizando en este sitio:

/* css para IE */
#cartel_ie {
    width: 428px;
    padding: 10px;
    border: 1px dotted #F0F;
    font: 13px/1.5em Georgia, "Times New Roman", Times, serif;
    margin: 10px auto 5px 249px;
}
#cartel_ie .titulo {
    font: 16px "Courier New", Courier, mono;
    color: #F0F;
}

¡Los invito a hacer una movida similar en sus sitios web personales! Un pequeño banner no basta.