Nota: Este post es parte de una serie titulada Consejos para Enfrentar un Proyecto Web y viene después de Del Mockup al CSS

Una de las cosas más importantes y potencialmente peligrosas del mundo web actual es el uso de Javascript. La aparición de frameworks como jQuery, MooTools, Prototype, YUI, etc., le han dado nueva vida a este lenguaje que solía ser un gran dolor de cabeza, sobre todo para nóveles programadores, por la dificultad para comprender el DOM, lo tedioso que significaba hacer cosas realmente serias (más allá de hacer una ventana pop-up con un tamaño determinado y poco más) y los problemas que implicaba hacer un código crossbrowser.
A esto se le une AJAX, este conjunto de tecnologías que, al combinarlas, nos permiten manipular datos vía javascript de forma asíncrona y sin necesidad de refrescar toda la página. La aparición en nuestras vidas de Gmail (de honorable memoria) fue el fenómeno que realmente nos hizo pronunciar las palabras mágicas de todo buen geek: AJAX FTW!
Claro, no todo es dulzura en las intarwbz. La facilidad en la que se ha convertido el uso de javascript (sobre todo por librerías como jQuery) también ha sido motivo del abuso que se ha hecho de él. Evitar esos abusos será la misión de este post.

1. Dile No al javascript obstrusivo

   Uno de los grandes males que han hecho a la humanidad editores como Dreamweaver (y yo amo a DW) es la utilización de javascript dentro del HTML (lo que se conoce como javascript obstrusivo). Nunca será suficiente decir que combinar XHTML con CSS y Javascript en la misma página es una terrible idea. Afortunadamente, es una práctica que va desapareciendo, pero es común verla sobre todo en quienes comienzan. Entonces, para evitar eso, digásmoslo de una vez: El código javascript (todo el código) debe ir en su archivo correspondiente, jamás mezclado con el HTML. Luego podrás llamarlo desde tu página usando la etiqueta <script></script>.

2. Comenta tu código, no seas perezoso(a)

   Cuando escribimos código -confesémoslo- tenemos la costumbre de hacerlo todo de una vez (o al menos a una velocidad que nos permite rápidamente saber qué hacemos), sin embargo solemos pagar el precio de no haber hecho comentarios cuando tenemos que revisarlo después de un tiempo (que puede ser un mes o menos incluso) y no nos acordamos de qué fue lo que hicimos o, peor aún, cómo demonios hicimos que funcionara.
   Sí, es cierto, debemos mantener los archivos lo menos pesados que podamos, cada línea cuenta y cada byte también pero -y para ello está los dos puntos siguientes- nuestros archivos deben ser reusables (no tiene ninguna gracia tener que escribir el mismo código una y otra vez) y en ello hacer comentarios es invaluable. Esto es doblemente importante si estamos hablando de un plugin, por ejemplo, que puede luego ser utilizado por otros. No es nada agradable tener que adivinar cómo lograste curar el cáncer por medio de javascript.
   No es tampoco que tengas que escribir un tratado sobre tu código. Pequeños y precisos comentarios serán suficientes. Recuerda: keep it simple.

3. Descomprimido para desarrollo, comprimido para producción.

   En nuestra lucha de mantener nuestros archivos al mínimo, una gran herramienta es la posibilidad de comprimir nuestros archivos. Al hacer esto, eliminamos tanto los comentarios como los espacios en blanco innecesarios, reduciendo por suspuesto el tamaño del archivo.
   El inconveniente que tiene esto, sobre todo a la hora de volver a nuestro js para hacer cambios, adiciones y/o mejoras a nuestro código es que éste será -cuando menos- difícilmente comprensible por nosotros mismos, cuando no ilegible. Es por eso que prefiero mantener mis archivos originales intactos (con sus comentarios, saltos de línea y formato) y una versión comprimida que será la que irá al servidor de producción. De esta manera siempre puedo hacer los cambios que necesite sin comprometer mi (poca) salud mental ni mi maltratada vista.
   Para hacer esto hay cientos de herramientas: compresores online, scripts php (como el proyecto Minify) o add-ons de Firefox (como Page Speed). Excepto en el caso de Minify, que se encarga de hacer la compresión al vuelo haciendo innecesario crear archivos comprimidos aparte, puedes mantener tus archivos en una carpeta (en mi caso los pongo dentro de una carpeta llamada _development, dentro de la carpeta js) y subir sólo los archivos comprimidos, teniendo lo mejor de ambos mundos.
   Valga el comercial no pagado, si usas Firefox y no tienes Page Speed realmente te recomiendo que lo pruebes. Yo solía usar el add-on de Yahoo!, YSlow, pero Page Speed tiene varias mejoras respecto a éste que me hicieron cambiarme. Que se encargue de comprimir los js y css es una de ellas.

4. Mantén tu código en un sólo archivo

   Sobre todo cuando trabajamos con algún framework e incluímos uno o más plugins, tenemos el problema de tener varios archivos, cada uno para cada cosa. Como decía antes, esto es muy bueno para el desarrollo, pero con un costo innecesario en archivos por descargar en producción. Nuevamente en este caso, Minify se encarga de unir todos los archivos por nosotros, pero si por alguna razón no podemos o no queremos usar esta herramienta (personalmente he tenido ciertos problemas cuando no tengo tiempo de sentarme a resolverlos, pero sé de gente -seguramente más lista e inteligente- que lo usa sin inconveniente alguno). En caso de hacerlo a mano, bien podemos crear un nuevo archivo donde colocaremos todo nuestro código comprimido, siendo éste el que subiremos al servidor. Recuerda que nuestro objetivo final no es sólo hacer que nuestros archivos pesen lo menos posible sino reducir también las llamadas al servidor, mientras menos llamadas, mejor.

5. Javascript no es CSS, favor no confundir

   A medida que javascript se hace más sencillo de trabajar y en consecuencia más poderoso -entre otras cosas- para manipular el DOM, es muy fácil abusar de sus bondades sobre todo a la hora de manipular el contenido (por medio de AJAX, por ejemplo) o el aspecto visual (haciendo que javascript reemplace atributos CSS o usando algún método de reemplazo de fuentes, como Cufón).
   Volveré al viejo tema: Progressive Enhancement, añade no sustituyas, crea pensando en lo más básico y luego añade funcionalidad a medida que el browser cliente pueda aceptarla.
   Si la pereza o la emoción te hacen olvidar que es CSS y no a Javascript a quien le corresponde el aspecto visual le darás una pobre experiencia a los usuarios que por alguna razón no puedan activar javascript en sus browsers o simplemente estos no lo soporten.
   Si hablamos de contenido. Es claramente un error grave respecto a SEO y semántica. No olviden que los buscadores (y los exploradores para ciegos) no pueden leer javascript.
   ¿Cuál es la solución entonces? Lo que he dicho antes, trabaja en base a un buen CSS y luego utiliza javascript para mejorar la experiencia de usuario, tanto a nivel visual como de funcionalidad.
   Hay, sin embargo, una excepción a esto y es cuando por razones de seguridad deseas epecíficamente que ciertos elementos no se presenten si no está activado javascript, como por ejemplo, para permitir comentarios o mostrar una dirección de correo electrónico de la que no quieres que se enteren los bots de spam.

6. Carga el javascript al final de tu (X)HTML

   Si bien lo normal es cargar el CSS dentro de la etiqueta head, en el caso de los archivos javscript se recomienda que sean cargados al final del archivo. La razón principal para hacer esto es que te permite cargar todo el contenido y los estilos antes de la funcionalidad, evitando que el usuario deba esperar a que el código también se cargue para comenzar a ver algo de tu sitio. Recuerda, el internauta es un ser impaciente, apenas tienes unos 5 segundos para evitar que tus usuarios abandonen tu sitio para navegar por otras tierras que no le hagan esperar una eternidad…

7. No todo requiere un plugin

   Ya que estamos con el tema de los frameworks (aquí debo decir que yo sólo conozco jQuery, así que soy completamente ignorante respecto a otros frameworks de javascript) hay que hablar de otro vicio: el uso indiscriminado de plugins.
   Es cierto que son geniales y que te ahorran mucho trabajo (sobre todo cuando los tiempos no te dan para mucho), pero precisamente su generalidad en algunos casos resulta un problema porque aumentan innecesariamente el peso de nuestro javascript. En muchos casos resulta mejor (y a veces incluso más fácil) escribir tu propio código. Sé que al principio puede resultar complicado y arduo, pero ciertamente ganarás en ahorro de código y aprendizaje. En caso que no sea posible (o no tengas ganas de arrancar desde cero) puedes hacer el camino contrario, adaptándolo a tus necesidades y eliminando el código que no necesites.

Y bueno, esto será todo esta vez. Si piensan que me dejé algo en el tintero (que seguro lo hice) o hay alguna cosa sobre la que quisieran que conversáramos, me encantaría leer sus comentarios.

proyecto web, javascript, progressive enhancement, desarrollo, front-end development

Nota: Este post es parte de una serie titulada Consejos para Enfrentar un Proyecto Web y viene después de Consideraciones Generales.

Update: Hay una edición de este post en Cristalab: Cómo afrontar un proyecto web. Parte 1: Del Mockup al CSS.

En esta ocasión, trataremos tres partes del proceso que son fundamentales en el desarrollo de nuestro proyecto web. En este caso hablamos del diseño de un sitio web en XHTML, pero parte de las consideraciones escritas aquí valen también para otro tipo de proyectos/tecnologías.

1. Mockup: Piensa, Intenta, Borra, Piensa, Intenta de Nuevo.

   La ventaja de hacer mockups antes de comenzar a maquetar es que te permite experimentar diferentes estructuras para el sitio, buscar las fórmulas que funcionen mejor en cuanto a usabilidad, accesibilidad y legibilidad.
   Al contrario de lo que algunos piensan, el momento de la planificación inicial es uno de los más críticos en el proceso de realización puesto que mientras más tiempo inviertas en organizar tu sitio/aplicación, menos tiempo gastarás haciendo modificaciones de última hora o resolviendo imprevistos, como que de repente a tu cliente se le ocurra que quiere agregar un link a la cuenta de Twitter que su hijo le abrió el día anterior.
   Este es entonces el momento perfecto para hacer lo que se conoce como “análisis de software”. Pensar en cómo será el producto antes de comenzar a crearlo es avanzar el 50% del trabajo, sin haber escrito una línea.

2. Mientras Más Propuestas, Más Problemas.

   Aunque a primera vista te parezca que darle varias opciones a tu cliente te hará quedar como un genio y es -en sí- una gran idea, realmente no lo es, al contrario es una idea pésima. A excepción de unos muy pocos clientes, que debes atesorar el resto de tu vida, que tienen una cierta idea de lo que significa tener presencia en la web y cómo eso puede reportarles beneficios reales y -sobre todo- que tengan una idea más o menos clara de lo que realmente desean, la mayoría de los clientes son como niños que comienzan a entrar en el mar: No tienen real idea de lo que están haciendo y de cuánto puede influir el diseño en el éxito o fracaso de su sitio.
   Siempre recordaré a aquel cliente que una vez me dijo que quería tener muchas propuestas, como cuando compra un automóvil, que puede escojer entre una amplia gama. Tuve que explicarle que en su caso sería como pedir tener una amplia gama de automóviles hechos a mano para poder escoger: ninguna empresa hace eso porque la pérdida sería mayor a la ganancia.
   Lo que suele ocurrir la mayoría de las veces es que presentas una serie de diseños diferentes y la selección final es la combinación de partes de un diseño con partes de otro y así hasta el infinito. En otras palabras: más propuestas sólo aumentarían la indecisión del cliente y, por un lado atrasarían el proyecto (porque necesitaría más tiempo para decidirse), mientras por el otro hay más posibilidades de que la escogencia final sea un diseño completamente diferente, una especie de Frankenstein web hecho con piezas de tu propuesta.
   ¿Solución? Presenta dos -máximo tres- propuestas y prepárate.

3. Maqueta de Forma General y Flexible.

   Tu mejor arma es pensar fuera de la caja, ir más allá que cobrarle por hacer ese pequeño portal de lindos colores y grandes imágenes. Si tu cliente te resulta fiel, querrá que te encargues de cosas como el mantenimiento del sitio o de sus futuros rediseños. Si no quieres que estas futuras tareas se conviertan en un verdadero dolor de cabeza, lo mejor es buscar una forma de maquetar (y con maquetar me refiero a (X)HTML) de tal manera que los futuros cambios no impliquen ninguna o la menor cantidad posible de cambios en la estructura del sitio. No importa lo fácil o difícil que resulte cambiar o no una o dos etiquetas, si la estructura está bien hecha ¿por qué deberías cambiarla? Lo ideal siempre sería que un cambio en el diseño pueda realizarse con CSS y/o cambiando las imágenes correspondientes, sin necesidad de tener que repensar sobre la estructura o la legibilidad de tu sitio.
   Por otro lado, mantener una estructura general y flexible siempre te permitirá crear plantillas/snippets que funcionen en casi todos tus proyectos, haciendo más eficiente la reusabilidad.

4. Semántica, Estándares, Validaciones.

   Sí, quizá yo sea un purista (aunque espero por el FSM que no sea así), pero al menos en los dos primeros casos me parece que lo mejor es apegarse a la norma; en el tercero acepto cierta flexibilidad. Aún recuerdo a Freddie diciendo una gran verdad: Si un sitio cumple su objetivo (generar dinero) ¿Qué demonios importa si el sitio es válido?
   No puedo decir que Freddie no tenga razón, después de todo, es un negocio de lo que hablamos, pero también es cierto que un etiquetado y un css válido permiten una interpretación más fiel en los navegadores y ayudan a conservarlos en el tiempo. Personalmente me preocupo por la validación pero dando prioridad a la funcionalidad. Sé que hay gente que piensa que no sirve de nada, incluso he oído gente que cuestiona los estándares por ser impuestos por la W3C, pero en ese caso, lo dejo a criterio de cada quien. si te funciona, está bien por mí, pero, por amor a lo más sagrado, ¡deja de maquetar con tablas!
   Ahora, sobre la semántica y los estándares, creo que nisiquiera merece la pena la discusión. Creo que es más que obvio que estas dos herramientas juntas son prioridad sobre todo en orden al SEO y la accesibilidad.

   Personalmente, procuro maquetar siempre bajo XHTML Strict, lo que me ayuda a descubrir posibles errores (como que olvide cerrar una etiqueta o colocar un “alt” a una imagen) y  CSS2.1.

5. Inspírate en Quienes Quieras, No te Copies de Nadie

   Nadie quiere ser reconocido por robarse el trabajo de otros, aunque de un tiempo a esta parte parece estar de moda creer que es válido tomar cualquier cosa de internet y hacer creer que son propias, o peor aún, pedir a otros que “nos regalen” la solución a nuestros problemas, como si preguntar en un foro equivaliese a encontrar una manada de esclavos que hagan el trabajo por el que yo voy a cobrar. No, nadie quiere ser reconocido de esa forma.
   Sin embargo, es perfectamente válido mirar el trabajo de otros, ver cómo solucionan los retos que sus proyectos representan, decubrir nuevas paletas de colores o formas ingeniosas de lidiar con el proyecto. Nadie puede acusarte de inspirarte, pero copiarte sólo te dará mala fama en internet (de eso puedes estar seguro) y, en algunos casos, hasta acarrearte problemas legales.

6. Usa un CSS Reseter

   Todos los que hemos maquetado sitios sabemos el dolor de cabeza que significan los navegadores y sus interpretaciones particulares del CSS, por lo que un Reseter que nos permita partir de un punto en común resulta un gran aliado a la hora de solucionar problemas con esto. No siginifica que todos los problemas de modelo de caja quedarán resueltos (el trabajo no puede ser tan fácil), pero sí que ayuda mucho a resolver al menos los más comunes.
   Aquí veo venir la pregunta obvia: ¿Cuál reseter usar? Hay cientos en internet. Lo mejor que puedo hacer es hablar de mi experiencia: Comenzar usando uno relativamente general y luego irlo personalizando de modo que funcione de la mejor forma posible para tus proyectos. Algunos de los más populares (que conozco) son el Tripoli Reset (en este artículo de Daniblog se explica muy bien y en español), el CSS Reset de Eric Meyer y luego, frameworks CSS como 960, YUI o el muy popular Blueprint.

   ¿Por qué personalizarlo? No es que sea obligatorio, pero quizá haya cosas que no te gusten del Reseter que selecionaste (como que quite el “bold” a la etiqueta “strong” o que elimine las viñetas de las listas), si ese es el caso, bien puedes irlo ajustando a tus necesidades y forma de trabajar.

7. Ordena y Comenta tu CSS

   Hay pocas cosas tan molestas como encontrarse un código sin comentarios que te obliga a leerlo todo para entender por dónde van los tiros. El CSS (aunque no es código) no es la excepción. Escribir los estilos como se te vayan ocurriendo sólo te asegurará dolores de cabeza al tratar de arreglar algo después de haber cerrado el archivo o -peor aún- a la hora de hacer un rediseño.
   Es por eso que son tan importantes los comentarios como el orden en que se escriben los estilos (Recuerda que los estilos son en cascada, es decir, un estilo se sobreescribe con el siguiente en el orden en que aparecen en el CSS). No tienen que ser extensos comentarios explicativos, puede ser simplemente para separar el código. Yo suelo dividir mi CSS de esta manera:

   1. Reseter
   2. Etiquetas
   3. Layout (Estructura General del Sitio)
   4. Elementos (Los elementos internos del Header, el Contenido, el Footer…)
   5. Clases (Que no están necesariamente vinculadas con una parte específica del documento)

   En cada división coloco un comentario para localizarlas más fácilmente. Hay formas más elaboradas para hacer esto, pero yo prefiero cosas sencillas y efectivas. Lo realmente importante es que sea un documento legible y que evite tener que estudiar en el MIT para poder hacer cambios al CSS

8. ¿Progressive Enhancement (Mejora Progresiva) o Graceful Degradation (Degradación Agraciada?)?

   Otra de esas discusiones eternas con argumentos válidos de cada lado. Personalmente soy partidario del Progressive Enhancement, pero una vez más digo que no hay que cerrarse a diferentes perspectivas. Por lo tanto, mi consejo es evaluar qué es mejor para cada proyecto y utilizar la técnica que resulte más efectiva para cada caso. Esto sobre todo es cierto cuando se trata de rediseñar un sitio, puesto que te encuentras frente a algo que ya ha hecho otro (o tú mismo) desde una de las dos perspectivas. Si me permites el consejo, dale prioridad al Progressive Enhancement sobre todo si vas a construir el sitio desde cero.

Bien, creo que con esto tenemos bastante, como siempre, hay cosas que se quedan en el tintero y cosa que podrían profundizarse más, pero este artículo sería interminable y no es la intención. Sería de gran ayuda leer sus impresiones y críticas, además de nutrirnos todos con sus experiencias.

En nuestro próximo encuentro, charlaremos acerca de Javascript.

Etiquetas Technorati: diseño, arquitectura web, progressive enhancement, proyecto web, css, xhtml, mockup

El pasado sábado 18 fue el último día de las Conferencias de Adobe En Vivo en su versión online. Cinco días llenos de interesante información, excelentes conferencias de personas provenientes de Perú, Colombia, República Dominicana, México, Argentina, E.E.U.U., Chile, España y Venezuela.

Lamentablemente sólo pude asistir a algunas conferencias, incluso el sábado, pero debo destacar el nivel de las mismas, así como una interesante asistencia de varios países de Latinoamérica y uno que otro español que seguramente veía la charla entre cabezazos de sueño

Fue toda una experiencia. Si crear un evento de medio día online es un gran dolor de cabeza, no me quiero imaginar lo que pudo haber sido coordinar cinco días de conferencias con todos estos husos horarios diferentes. No me extraña que la mayoría de los asistentes fuesen peruanos.

Debo decir que fue excitante, como ahora mismo estoy trabajando en El Mundo Real™ en algo no relacionado a las intarwbz y sin conexión disponible (seee, apesta, lo sé) sólo pude asistir a un puñado de conferencias (sábado incluído), pero no podía esperar llegar a casa para conectarme y ver de qué hablaban en ese momento.

Los temas fueron de lo más variopintos: desde Video hasta técnicas de optiimización para sitios web, desde marketing hasta el futuro de la web. Toda una experiencia.

Tampoco quiero que parezca que le doy propaganda gratis al evento o que escribo esto porque me pidieron dictar una conferencia, realmente me pareció genial y -aunque dudo que tengan ganas- sería genial que la repitiesen en otra oportunidad aunque no me inviten

Prefiero que uds. mismos/as puedan evaluar el evento, lo que será posible porque la gente de Garage Flash se encargó de colgarlos (vía Connect) para el disfrute de la audiencia. Eso sí, no son descargables. La lista entera de las conferencias la hallarán aquí.

¡Que disfruten!

Actualización: Hoy, martes 14, me he dado cuenta que me había equivocado con la fecha de inicio del evento, que no fue ayer (13) sino hoy (14). Pido disculpas.

También me he enterado que, aparte de esta serie de conferencias, habrá un evento presencial de Adobe En Vivo en Lima, como ocurrió el año pasado.

El año pasado, los amigos de Garage Flash (AUG) celebraron su aniversario con una gran evento que combinó conferencias de propios y foráneos con una semana completa de cursos presenciales, en Lima, Perú.
Para este año, han decidido hacer algo completamente diferente. Desde hoy martes 14 de Julio y hasta el sábado 18, Adobe En Vivo será completamente online!
En efecto, hoy comienzan las charlas vía Adobe Connect y continuarán el resto de la semana, con una veintena de expositores, tanto del Perú como de Colombia, República Dominicana, España, México, Ecuador, Chile, Argentina, Estados Unidos, Bolivia y Venezuela.
Será todo un maratón y, a excepción del año pasado, será completamente online.

Así que, sólo debes ir a la página de Adobe En Vivo Online y mirar qué charlas deseas ver y a qué hora será. Debes recordar que el horario es GMT-5 (horario de Perú) y hacer los cálculos pertinentes para tu país.
Por cierto que para este año se me ha pedido que de una de las conferencias, por lo que estaré el sábado 18 hablando sobre el Progressive Enhancement. Allí nos veremos (si mi apestosa conexión no me juega una mala pasada, claro )

Nota: Este post es parte de una serie titulada Consejos para Enfrentar un Proyecto Web y viene después de Intro.
Bien, comencemos con consideraciones que debemos tener en cuenta incluso antes de comenzar a trabajar. Debo decir que esta lista la he hecho pensando en freelancers (porque yo mismo lo soy), pero muchas de las cosas que están aquí son válidas para no-freelancers también:

1. Procura hacer un cuestionario corto y preciso, que te permita luego crear un brief.

   La clave de un buen cuestionario es usar pocas preguntas, fáciles de contestar. Por lo general, tu cliente quiere dejar la mayor parte del trabajo tedioso de tu parte; además, si es una persona ocupada, no querrá agregar a su lista de tareas la de tener que hacer grandes cuestionarios o supervisar lo que estás haciendo, así que lo mejor para él (y para ti) es que le facilites lo más posible su parte del trabajo en la creación del proyecto. Eso sí, una vez que tengas el brief listo, no olvides enviárselo para que te dé su visto bueno.

2. Ten al menos una reunión con tu cliente para hablar sobre el proyecto.

   Esta puede ser presencial, vía telefónica u online (Skype, GTalk, Messenger, etc.) La reunión no puede ser por escrito. No significa que todas deban ser de esta manera, pero al menos la primera debe serlo. Todos sabemos que una conversación donde pueda -al menos- escucharse la voz de la contraparte resulta más fluida y productiva que una conversación escrita, que es más estructurada pero no permite la inmediatez de la primera; a eso hay que incluir ese “extra” que significa el tono de la voz y la capacidad de ganar la confianza de tu cliente a través de una buena conversación. Si puedes tener un par de conversaciones más con tu cliente, no las desaproveches. Ese tipo de contacto genera relaciones que duran en el tiempo (si te portas bien, claro).

3. Prepara un contrato y no comiences el trabajo hasta tener la aceptación del mismo, por escrito, de parte del cliente.

   No hace falta tampoco que generes páginas y páginas para tu contrato, sólo procura que no falten los puntos esenciales: Descripción del Proyecto, Presupuesto, Forma(s) de Pago y Tiempos de cada etapa. Siempre es buena idea que te asesores con alguien sobre las formalidades requeridas en tu país. Por supuesto, para que un contrato sea válido debe estar firmado por ambas partes o al menos aprobado expresamente de algún modo.

4. Comienza siempre con un mockup.

   Ya sea que utilices el viejo pero bueno papel y lápiz, algún software o alguna herramienta online, no comiences a diseñar sin crear antes un mockup. A diferencia del proceso de diseño, en el mockup preocúpate por cosas como la navegación, la distribución del contenido, el formulario de búsqueda, etc. Luego tendrás tiempo para el proceso de diseño como tal. Además, el mockup te permitirá volver a plantearte la estructura o parte de ella con facilidad.

5. Ten siempre presente la posibilidad de que el cliente retrase el trabajo.

   Personalmente, mi problema principal a la hora de intentar mantener los tiempos es que el cliente entregue el material, haga las revisiones en el tiempo establecido, etc. Para paliar ese problema suelo hacer dos cosas (no necesariamente al mismo tiempo):

   1. Colocar tiempos de revisión -normalmente de una semana- por parte del cliente, advirtiéndole que cada día de retraso implicará un cambio en la fecha de entrega y/o un recargo (de un 1%, máximo) en el precio final. Si quieres que se apure, tócale los bolsillos.
   2. Preveer estos retrasos, dándole más tiempo a los lapsos de entrega de material o revisiones. Esto no es la mejor solución, pero si conoces más o menos a tu cliente, puede funcionar.

6. Piensa en el usuario final, que tu sitio sea usable y accesible.

   El cliente a veces tiene la razón, pero es tu obligación hacer lo mejor que puedas por él. Hazle recomendaciones, dile por qué tiene sentido tu diseño. Eso sí, ten cuidado con terminar defendiendo tu diseño sólo porque lo hiciste tú y estás enamorado de él. No tengas como prioridad satisfacer a tu cliente sino a su cliente, que será quien tenga que interactuar con lo que hayas hecho. Ten en cuenta que el 80% de tus clientes no entieden que un sitio web es un medio de comunicación y no sólo una tarjeta de presentación.

7. Sé un profesional o no te vendas como tal.

   Sí, suena duro, pero eso cierto. Todos sabemos el dolor de cabeza que significa “el sobrino que sabe de computadoras”.
   No estoy diciendo que te vendas como el mejor diseñador/desarrollador del mundo, pero tampoco debes hacer pensar a tu cliente que no estás calificado para el trabajo o que simplemente eres su sobrino de 12 años. Si te vendes por centavos, no sólo te perjudicas tú (porque siempre esperarán que te vendas por centavos) sino a todo el mercado, creando el precedente de que el diseño web es cuestión de limosnas.
   Por otro lado, debes estar consciente de tu papel, tu cliente espera que resuelvas un problema, no que los crees; aún cuando estés comenzando, debes tener la suficiente seguridad para evitar que te vea como un repartidor de pizzas, si tú no te respetas ni respetas tu trabajo, tu cliente tampoco lo hará (ni la comunidad).

8. Estudia, lee, aprende.

   Una de las cosas más fascinantes de la tecnología es que está en constante desarrollo. Siempre hay cosas nuevas que aprender, los horizontes están en constante expansión. Si quieres permanecer en el mercado, ya sea que te dediques al diseño, al desarrollo o ambos, debes mantener “mente de principiante”, debes querer aprender cosas nuevas. Claro que no te volverás un experto en todo, pero al menos debes saber un poco de diseño, de desarrollo, de SEO, de estándares… esas son las cosas que marcarán la diferencia… o no.

En fin, ni esta lista ni las que vienen pretenden -ni mucho menos- ser la última palabra sobre este tema, hay cosas que faltan, cosas que pueden profundizarse y quizá cosas inútiles. Si les place, me encantaría saber su opinión al respecto.
Una vez dichas estas cosas generales, la próxima vez hablaremos más en profundidad sobre el Mockup.

Etiquetas Technorati: diseño, arquitectura web, progressive enhancement, proyecto web

No es que quiera inventar el agua tibia ni nada; es mucho lo que se ha escrito sobre este tema y existen cantidades de listas al respecto (lo sé porque he leído montones de ellas a lo largo del tiempo y no es poco lo que he aprendido).
Lo que quiero hacer aquí es intentar mostrar el modo como trabajo, tratando de explicarlo de la forma más sencilla y clara que pueda. La intención es tanto conceptualizar y estructurar las tareas como mostrar a quien lo necesite una forma de acercarse al problema y, por supuesto, escuchar sus comentarios y sugerencias al respecto, que aquí el que no aprende no gana.
Como esto se pinta largo (porque no quiero hacer simplemente otra lista de cosas por hacer), éste será el primero de una serie de posts al respecto que, espero, serán útiles no sólo para ustedes sino también para mí.
Para comprender mejor esta lista, creo que sería excelente que leyesen los artículos de A List Apart respecto a Progressive Enhancement, especialmente -a modo de introducción- Understanding Progressive Enhancement (eso sí, ambos en inglés).
Normalmente, cuando debo enfrentarme a un proyecto, el primer problema con el que debo lidiar es que el cliente desea ver un boceto sin antes siquiera decirme de qué se trata la empresa/negocio/lo que sea que quiere poner en la web. Siempre tenemos el problema de que la gente se preocupa más por el “eyecandy” y menos por lo más importante: el contenido, hacer que todo tenga sentido.
La forma que he encontrado de (más o menos) lidiar con ello es, en resumidas cuentas, hacer un cuestionario lo más directo, sencillo y corto posible, que publicaré luego) para tener al menos una idea de en qué me estoy metiendo antes de comenzar; esto, sin embargo, debe ser seguido -de ser posible- con una plática directa con la persona encargada del proyecto.
Un vez dicho esto, vamos a dividir el proyecto en etapas que serían:

1. Consideraciones Generales.
2. Mockup.
3. Maquetado.
4. Diseño.
5. Programación.
6. Contenido.

En base a esta lista general, iremos viendo qué hacer y qué no en cada etapa. La intención de todo esto es poder crear sitios que sean accesibles, usables y que puedan funcionar incluso sin javascript ni css (un sitio bien hecho debe ser igualmente accesible para browsers con javascript/css activados como para browsers que sólo lean texto).

Etiquetas Technorati: diseño, arquitectura web, progressive enhancement, proyecto web

Seguramente ya sabes -o al menos has oído hablar- de Twitter, la herramienta de microblogging (de la que ya hablamos en este blog) y, si me conoces un poco, sabrás también que soy un adicto a la cosa esa.
Desde hace mucho tiempo he buscado fórmulas para crear/hallar/entrar en la comunidad web venezolana, por una cuestión de desarrollo del mundo/mercado web en Venezuela, como ocurre en otros países, así que me pareció lógico pensar que habría por allí más de un coterráneo que se dedicase a las lides del diseño web y/o la bella tarea de escribir código con el típico sabor a arepa con queso de mano que sólo se ve en esta tierra (y claro, pensando que la comunidad me soportaría).
Por supuesto que yo ya sigo a venezolanos que diseñan/desarrollan: psycho_vnz, torrealbaruben, la encantadora roba gatos, Takag y la temible y admirada Xklibur_clab, altos panas (grandes amigos para los no-entendidos); pero los tres tienen conmigo otra cosa en común: Cristalab,la comunidad a la que pertenecemos y en la que los venezolanos (al menos por número de registrados) aún somos un grupo pequeño (si se compara, por ejemplo, con mexicanos, peruanos y colombianos). También, gracias a un evento online donde estaban metidos los clabbers, me encuentro con una programadora que vive/trabaja/hecha_carro/goza_un_mundo en Margarita: la genial alita3107
Bueno, la cosa es que, ya no recuerdo cómo, termino siguiendo a cannibalita, una pana que se define a si misma como:

♥ diseñador gráfico, artista plástico, músico ♬♫♪♬, junkie =)

metalera hasta las patas y además maestra de arte (o algo así) en un colegio.
Hasta ahora todo va como se debe, al menos es diseñadora gráfica (como torrealbaruben), aunque me parece que no está metida en las lides de las intarwbz.
Por medio de cannibalita me entero de un chamo, entregado al Software Libre y, según él mismo dice, “pichón de BOFH”: willicab. Luego me entero que ambos leen un blog dedicado a hablar de ciertas series de TV que me gustan, principalmente sobre “24″ y que siguen a su autora, cuyo nick es sumamente descriptivo: Adictisima; y yo, como buen curioso, voy y leo el blog y me gusta así que la sigo.
A partir de aquí es que todo toma otro rumbo.
Siguiendo a estos divertidos personajes, caigo en una vorágine de gente de lo más variopinta, con dos cosas en común: venezolanos y geeks (al menos la mayoría); pasemos lista:

• kudry: Estudiante de 16 años, emprendedor y humano. WTF? ¿emprendedor de 16 años? Hay que ver qué es lo que tiene este muchacho, la mayoría de muchachos de 16 años piensan en cualquier cosa menos en emprender.
• jaycer17: Periodista, cinéfilo entregado que lleva (o trata de llevar) tres blogs y a quien nombré hace poco en el post sobre el aniversario de The Matrix; eso sí, mosca con hablarle de bajar películas y tal, porque es bastante estricto con el tema. Si no me equivoco, escribe en algún periódico/revista sobre cine, pero soy completamente ajeno a las versiones impresas de las noticias, así que no sé a ciencia cierta. Eso sí, el pana es una nota.
  
• JManzur: El único que conozco que vive en Maturín (la ciudad donde estoy viviendo ahora), pero que se la pasa viajando haciendo servicio técnico a cuanta computadora se deje. Además tiene un blog muy interesante sobre tecnología e internet.
• Kodisea: Otra periodista, feminista de las entregadas, amante de la cultura en general y la lectura en particular. Por cierto, vive en Ciudad Guayana pero muere por meterle el diente a Caracas y toda la actividad cultural que allí pulula.
• modulor: Arquitecto, profesor, y tambíen alguien muy activo en las intarwbz; todo un tipo 2.0, pues.
• ganarce: Desarrollador, creo que el primero que hallé (exceptuando a los clabers). Me recomendó mirar un mundo que aún no he podido visitar: Mootools. Prometo darle una mirada.
• rafaelochoa: Desarrollador de RIA’s, Flex Coder y entusiasta de la tecnología. Ah, cierto, y un novato en las lides fotográficas.

Hay más personas que voy siguiendo (ya saben cómo es, con los #followfriday y siguiendo los followers de otros), pero aún no sé bien quienes son; a eso hay que agregar diarios y medios de comunicación nacionales (ElNacionalWeb, ElUniversal, globovision, Noticiasve,…) que me resultan más como pequeños feeds en caliente. Mención especial merece unicasa, que corresponde a una cadena de supermercados venezolana, pero es posible que hable de ello en otro momento.

Primeras Impresiones

Debo comenzar diciendo que yo comencé en Twitter con un grupo de usuarios muy internacional: peruanos, argentinos, colombianos, mexicanos, chilenos y los venezolanos que comenté. Todos miembros de Cristalab, así que ya nos conocíamos, teníamos un lenguaje común y lo llevamos a Twitter.
Eso significa que me ha costado un poco “nacionalizarme” en Twitter, y descubrir cómo es la movida en este grupo (donde hay un buen número de periodistas, por cierto) en el que he caído. Supogo que hay otros grupos aparte de éste y que los iré descubriendo eventualmente.
También he visto que hay un buen número de ellos que son adictos a Tumblr, del que admito había escuchado alguna vez, pero pronto olvidé.
En términos generales, descubro una comunidad muy particular (a veces siento que debo escribir en “dos idiomas”), en la que no siempre parece fácil entrar, pero realmente interesante, dinámica y definitivamente adicta a Twitter.
Aún espero encontrar más diseñadores / desarrolladores e ir viendo cómo es la movida en mi país, claro, invitarlos a Clab (y que nos entreguen sus almas) y seguir descubriendo a gente interesante en el camino. No haré de mi blog una “bitácora de Twitter”, pero ya les contaré cómo me va en esta aventura.

El día 30 de Mayo de 2009, la gente de Tequila Valley y Forum Nokia estarán celebrando el MobileCamp México, en el que, tal como ellos mismos dicen, “se hablarán de todas las tecnologías móviles y todo tipo de dispositivos.”
El lugar, tentativo para llevar a cabo el evento, es el Centro Cultural Universitario Tlatelolco desde las 9 a.m. hasta las 7 p.m.
Si vives en La Ciudad de México o alrededores, o simplemente estarás ahí ese día, deberías aprovechar la oportunidad de participar en este barcamp y conocer a otros locos como tú! (nada como la falta de cordura y el amor por los gadgets compartidos )
Si vas al evento y tienes un blog, sería muy c00l que compartieras tus experiencias con otros menos afortunados que estaremos algo lejos (varios países por medio) del MobileCamp México.

Por cierto, también puedes seguir a mobilecamp Mexico a través de su cuenta en Twitter: MobileCampMex.

mobilecamp, mexico, eventos

Seguramente ya conoces el Show británico “Britain’s Got Talent” (y/o su hermanito gringo “America’s Got Talent“). Básicamente es una competecia de talentos donde entra todo el mundo que demuestre que lo tiene, como un “American Idol” pero no sólo para cantantes.

La cosa es que, ayer por la tarde, llega kudry y deja caer esta perla en Twitter:

La Paul Potts mujer: http://tinyurl.com/d7c5gw

El link lleva a un artículo de ALT1040 que, básicamente, se explica por sí solo al ver esto:

Creo que no hay mucho más que decir, excepto Wow!!! y morir de vergüenza con masculinas lágrimas en los ojos.

Si no sabes del show y/o no conoces a Paul Potts, el ganador de la temporada pasada, mira su presentación al casting de Britain’s Got Talent:

Así que al final sí habrá que tener cuidado de juzgar a la gente por su apariencia…

Update: He cambiado los videos de Youtube por otros de Dailymotion debido a que Youtube no permite que se embeban los videos de BGT (gracias, Dientuki, por el aviso).

Ayer, 31 de marzo, fue un día glorioso para todo geek que se precie: el décimo aniversario de una de las trilogías más impactantes del mundo del cine, de esas que luego de mucho tiempo (10 años, ni más ni menos) siguen marcando un antes y un después en el mundo del cine y sigue siendo un patrón (entre otras cosas respecto a efectos especiales) en las películas de acción: The Matrix.
Esta obra de arte de los hermanos Wachowski ha sido de las trilogías más exitosas de la época moderna, capturando desde geeks hasta amantes de la acción y filósofos (entre los que me incluyo).
Yo no soy cinéfilo y mucho menos un entendido del tema, así que esas cosas se las dejo a los que saben (como el recién descubierto pana Juan Carlo Rodríguez y su blog de cine, que hace también un post al respecto), en este pequeño post hablaré de mi experiencia personal (como de costumbre )
Cada una de las películas de la trilogía tiene un tópico específico, que apunta directamente a un elemento vital de la vida humana, a una pregunta filosófica que, no sólo da norte a la película sino que invita al espectador (en caso de que este pueda ir un poco más allá de las peleas y los efectos especiales) a mirar en profundo.
En Matrix I, todo se centra en Neo, su autodescubrimiento, cómo despierta de su engañoso sueño y cómo es capaz de ver la realidad y actuar efectivamente sobre ella (no hablaré mucho más de eso porque no quiero parecer libro de autoayuda). Neo descubre que sus sospechas de hay algo que no está bien en el mundo no son infundadas, que aún no sabe quién es y -con la ayuda de Morpheus, The Oracle y la propia Trinity- va descubriendo que la puerta que lo lleva al conocimiento de la verdad pasa por el famoso noscet te ipsum (“conócete a ti mismo”), la pregunta por el sentido de la propia existencia, de todo lo que existe…
El otro elemento que da norte a esta película es el problema del Libre Albedrío, La Autodeterminación y, en última instancia, la Libertad (no sólo como libertad para decidir sino como libertad responsable, con consecuencias a enfrentar). Neo no sólo batalla para librar al mundo de las máquinas, lo hace para descubrirse a sí mismo, para poder autodeterminarse, para ser libre y, por medio de ese camino, dar a otros la oportunidad de ser libres también.
Alrededor de ello hay otros temas que dan sentido a la trama: Las relaciones interpersonales como forma de auto-descubrimiento (hallarse en otro), la tecnocracia como un peligro latente, la mente humana como la gran máquina e incluso el problema de la Verdad o la percepción de la realidad.
Hay mucho que podría decir de Matrix desde varios ángulos. Baste comentar que es, posiblemente, una de las películas más complejas, atrapantes e increíbles que he visto en mi vida (junto, quizá, a The Lord of The Rings, aunque en un nivel diferente) y que junta maravillosamente filosofía, anime, juegos de rol… en una excelente película de acción que, diez años después sigue siendo punto de referencia obligada en el cine.
Te guste o no, The Matrix has You…