Tzek Blog de Diseño » XML/CSS http://tzek-design.com/blog Diseño de Información e Interacción: Reflexiones, comentarios, vínculos con otras áreas de diseño o bien, cualquier cosa... Wed, 01 Sep 2010 21:18:42 +0000 http://wordpress.org/?v=2.8.6 en hourly 1 Beca Alzado 2008 http://tzek-design.com/blog/2008/10/24/beca-alzado-2008/ http://tzek-design.com/blog/2008/10/24/beca-alzado-2008/#comments Fri, 24 Oct 2008 16:16:35 +0000 Tzek http://tzek-design.com/blog/?p=460 Es muy grato toparse con iniciativas como la de Alzado. Tal como aparece en su sitio web:

Resumen: 3.000 euros para la mejor idea para un proyecto web. En estos momentos de incertidumbre financiera, creemos que la Beca Alzado tiene más importancia que nunca. Por segundo año convocamos a cualquier persona a enviarnos su idea para un proyecto web. El plazo estará abierto todo el mes de Noviembre. Daremos la beca el 15 de diciembre.

Toda la información está en el post correspondiente. Aquí dejo un par de detalles que aparecen en dicho post que pueden animar a la participación.

Envía tu idea

El proceso sigue siendo tan sencillo como el año pasado. Envía tu idea en cualquier formato.

Puedes sencillamente rellenar el formulario, adjuntar un documento, poner enlaces a la web… lo que quieras. Lo que valoramos son las ideas. Evidentemente cuanto más detallada y elaborada, mejor se podra valorar y por tanto tendrá más posibilidades de llevarse la beca.

Quién puede enviar su idea

- Desde cualquier país.
- Cualquier persona (edad, sexo, creencia…).
- El texto del proyecto puede estar en inglés o castellano.
- Ideas destinadas a internet. Portales, aplicaciones, contenidos, tiendas, diseños, comunidades… Cualquier cosa. El año pasado se recibieron ideas sobre productos industriales o productos físicos. Si bien eran ideas geniales, nosotros no somos los más adecuados para juzgarlas y por tanto preferimos descartarlas de entrada.

Es tu idea

En Alzado solo queremos apoyar a las ideas y a sus creadores. La idea ganadora, así como todas las ideas enviadas pertenecen a sus autores. La beca no compromete en nada al autor de la idea con Alzado.

Para que quede lo más claro posible: No queremos nada. Solo queremos apoyar a la mejor idea que encontremos.

Una vez pasado el proceso de selección todas las ideas enviadas serán eliminadas de nuestros archivos para siempre.

Si gustan, pueden ver el proyecto ganador del año pasado: Vi.sualiz.us.

]]> http://tzek-design.com/blog/2008/10/24/beca-alzado-2008/feed/ 0 Ciclo de Conferencias: Web 2.0 para Ingenieros y Diseñadores en Puebla, México http://tzek-design.com/blog/2008/10/14/ciclo-de-conferencias-web-20-para-ingenieros-y-disenadores-en-puebla-mexico/ http://tzek-design.com/blog/2008/10/14/ciclo-de-conferencias-web-20-para-ingenieros-y-disenadores-en-puebla-mexico/#comments Tue, 14 Oct 2008 22:25:07 +0000 Tzek http://tzek-design.com/blog/?p=452 Veo en la Vecindad Gráfica y BoxByte que la gira de conferencias sobre web 2.0, que a su vez promocionan el evento de “México Web 2.0″, tendrán su conclusión en Puebla, Puebla. Vendrán Armando Sosa y Adán Avelar de Vecindad Gráfica.

¡Excelente! Para los que no podremos ir a Cancún es un buen chance para conocer y escuchar a practicantes de los estándares y construcción de herramientas sociales en la Web. ¡Ahí nos vemos!

Por cierto, antes de que se me pase… Por si no los han visto, les recomiendo dar un vistazo a la serie de post del buen Sosa sobre cómo ser freelancer, los cuales se llaman “Lanzándose al vacío”.

Comenta Adán:

Como sitio final de la gira para dar a conocer el evento de México Web 2.0, que se llevará a cabo el 3 y 4 de Noviembre en Cancún, ahora visitamos Puebla:

Ciclo de Conferencias: Web 2.0 para Ingenieros y Diseñadores
Fecha:16 de Octubre
Hora: 13:00 horas
Lugar: Conexsoft 2008, Centro de Convenciones Puebla

Ponente: Adán Avelar
Hora: 13:00 hrs. | Duración: 30 minutos
* El impacto del Web 2.0 en el México de hoy

Ponente: Armando Sosa
Hora: 13:30 hrs. | Duración: 30 minutos
* Construyendo una nueva Web

Mesa Redonda con los ponentes
Hora: 14 hrs.

Apresúrate a registrarte para el gran evento el 3 y 4 de Noviembre en Cancún.
México Web 2.0

]]> http://tzek-design.com/blog/2008/10/14/ciclo-de-conferencias-web-20-para-ingenieros-y-disenadores-en-puebla-mexico/feed/ 6 Legibilidad de código y documentación http://tzek-design.com/blog/2008/07/26/legibilidad-de-codigo-y-documentacion/ http://tzek-design.com/blog/2008/07/26/legibilidad-de-codigo-y-documentacion/#comments Sun, 27 Jul 2008 02:22:21 +0000 Tzek http://tzek-design.com/blog/?p=403 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.

]]> http://tzek-design.com/blog/2008/07/26/legibilidad-de-codigo-y-documentacion/feed/ 1