Tag Archives: tutorial

Tutorial rápido para sketchnoting

Como parte del curso INFO-I300: Diseño de Interacción Humano-Computadora en la Universidad de Indiana en Bloomington, he creado un pequeño tutorial sobre sketchnoting. Esta es la primera vez que escribo mi razonamiento detrás de la manera en la que tomo notas. Fue una experiencia interesante. Mis insights derivados de este ejercicio sonÑ

  • Sketchnoting ayuda a organizarsintetizar información.
  • Sketchnoting ayuda a desarrollar pensamiento metafórico.
  • Sketchnoting ayuda a desarrollar un código visual personal para la información.
  • Las herramientas son importantes (e.g., marcador de punta de aguja, marcador de punta de pincel y libreta de bocetos de buena calidad).
  • Saber dibujar no es tan relevante. Las anotaciones tienen que tener sentido para ti primeramente.
  • Consistencia es un aspecto clave para sketchnoting.

Y con base a mi experiencia, los pasos para un buen sketchnoting son:

  1. Escuchar
  2. Filtrar
  3. Anotar
  4. Codificar visualmente
  5. Relacionar el contenido

Espero que la presentación de abajo sea de utilidad para los interesados en sketchnoting.

20 herramientas para hacer más fácil la vida al desarrollador web

Encontré este post de Nettuts+ de herramientas para desarrolladores web. Lo dejo aquí de referencia, en particular por el enlace que tiene a TypeTester, herramienta que está super-bien para checar color tipográfico en pantalla. ¡Ah! Y también por el generador de paletas de color de ColourLovers que resulta práctico cuando uno está en clase de diseño web.

20tools_nettuts

Ojalá les sea también de utilidad. ¡Saludos!

Combinar texto en InDesign

En Corel Draw!, desde sus primeras versiones, una función era la de combinar texto. Esto es muy útil en situaciones donde tienes un diploma base (el template) y en vez de cambiar el nombre una por una, jalas los datos de un archivo de texto plano (hecho en notepad o textedit).

Ahora bien, me han preguntado cómo hacer el equivalente en Illustrator. En la Adobe Creative Suite (CS), las cosas están un poco más separadas. No es como en Corel Draw! que es una medio combinación de Illustrator e InDesign). En CS lo de la combinación de texto se hace en InDesign. 

Dónde está la opción para jalar datos de un archivo

Ventana de Data Merge en Adobe InDesign CS

La ventana de Data Merge.
No olvides hacer clic en el menú de la "bolita-flecha" para acceder a las opciones.

Así que aprovecho este post para dejar un tutorial-interactivo en video de IconLogic, muy bueno, donde te explica como hacer el Data Merge (el nombre que tiene combinar texto en CS). La idea es la misma: tener el archivo con los datos, abrir la opción en InDesign, jalar el archivo, colocar los campos, rellenar los campos. Espero les sea de utilidad.

Tutorial: http://www.iconlogic.com/demos/InDesignCS2SampleDemos/DataMerge.htm

Alebrije

Hace un par de semanas, el buen Choper sacó un post titulado "Espíritu de Venado" en su blog personal. Este platicaba sobre una anécdota de darse tiempo para hacer cosas para uno mismo (diseño en general), sugiriendo dejar de pensar que si no nos pagan, no hacer algo.

Hacer algo ajeno al trabajo

Definitivamente yo no suelo hacer cosas personales de diseño, pero el post me dejó pensando: hacer cosas sólo de la chamba me pone en un estado no muy óptimo para diseñar, como enfadado o aburrido. Decidí entonces tomar un lápiz y dibujar antes de empezar algo del trabajo. Me dispuse a hacer un alebrije.

Alebrije Tzek

Alebrije (clic para ampliar).

Ponerme a dibujar es algo que solía hacer mucho y me ponía en un estado tranquilo. Contradictoriamente, me pongo a "garabatear" cuando supuestamente tengo que "poner atención", como en una clase o mientras platico largo y tendido sobre algo relevante. Quizá por eso no me pongo a hacer cosas de diseño después de decirme "Hoy voy a hacerme algo de diseño".

Ponerlo a colores

Me decidí a colorear mi alebrije, en fotochop... la neta, no me quedó como esperaba y eso de iluminar con el mouse requiere paciencia.

Alebrije a color (clic en imagen para ampliar).

Esta forma de iluminar simple (por favor ilustradores no se rían), va mas o menos así:

  • Aplicar al dibujo escaneado la opción de Desaturar.
  • Disponer de una capa encima del escaneado en modo Normal.
  • Dar varios brochazos de color con un porcentaje menor al 100% de opacidad y con la brocha en modo Color.
    • Mezclar con el dedo, también con menor a un 100%. Esto para ir mezclando los brochazos.
    • Tomar diferentes porcentajes del borrardor y hacer borrones, para dar "luz".
    • Repetir cuantas veces sea necesario.
  • Cuando ya se haya terminado de iluminar la pieza, duplicar la capa que corresponde a los colores. Una de estas capaz ponerla en modo Color (queda como se hubiera hecho lápices de color) y la otra ponerla con una opacidad menor.
  • Ajustar hasta obtener los trazos de lápiz en combinación con el color según como se desee.

En conclusión

Una parte definitivamente acepta que es un buen método para ponerse en blanco y luego concentrarse en el trabajo. Sin embargo, admito que resulta incómodo estar ahí bocetando para distraerte-despejarte sin levantar sospechas a quién pasa por tu escritorio.

Tutorial de Arquitectura de Información en Webmonkey

A principios de la década, a mi juicio, uno de los mejores recursos para los interesados en el diseño y desarrollo web era Webmonkey, gracias a sus buenos tutoriales y otros artículos. Entre los primeros se encuentra el "Tutorial de Arquitectura de Información Web".

Si necesitas conocer qué es y cómo se aplica este concepto en un sitio web, te recomiendo echarle un vistazo a este tutorial; su contenido es presentado con claridad, cubriendo los puntos necesarios en forma concisa.

Liga:
http://www.webmonkey.com/tutorial/Information_Architecture_Tutorial

¡Qué bien que Webmonkey está de vuelta! Un portal dónde se aplicaba bien el concepto de que el contenido es el rey. Espero que en esta versión se repita la historia.

Legibilidad de código y documentación

Justo que vi un comentario de Ixmael en el post sobre mis experiencias en rediseño de logos, me hizo recordar sobre la indentación y documentación al momento de escribir código. 

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.