Consejos para Enfrentar un Proyecto Web – Del Mockup al CSS

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

Adobe en Vivo Online ‘09

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 )

Adobe Catalyst – Diseños Interactivos sin Escribir Código

Si eres, como yo, un seguidor de El Gran Ojo, Adobe, seguramente ya te habrás enterado de Flash Catalyst, el nuevo proyecto que la compañía de la “A” lanzó en el MAX 2007 bajo el nombre clave “Thermo” y que ya entonces generó gran espectación.

La razón por la que la gente ha estado esperando tanto por esta nueva herramienta es porque disminuye aún más la distancia entre el diseño y el desarrollo, aunque más del lado de los primeros que de los segundos.

Adobe Flash Catalyst

Con Flash Catalyst puedes crear toda tu interfaz en Photoshop, Illustrator (Hola Mx <3) o Fireworks, dividida en sus respectivas capas/carpetas, importarla a Catalyst y comenzar a crear interacción ¡sin escribir ni una sola línea de código!. Catalyst se encargará de generar todo el código necesario para que tu aplicación responda como lo has planeado… ¡y todo sin matar ni un gatito!

En otras palabras, Catalyst promete lograr lo que no pudo hacer Flash respecto al diseño interactivo: prescindir del programador para las cosas sencillas como animar elementos o crear botones interactivos.

Sin embargo, aunque no lo parezca, Catalyst está más cercano a Flex que a Flash. De hecho, los archivos de Catalyst pueden ser abiertos en Flex para profundizar más en el desarrollo de la aplicación, cuando ésta así lo requiera y, de hecho, lo que los flasheros conocen como “símbolos”, en Catalyst son “componentes” propios de Flex.

En Catalyst es posible: convertir objetos estáticos en componentes (botones, barras de scroll, etc.), definir transiciones entre elementos, crear animaciones que involucran los ejes x, y, z (aprovechando el soporte del eje z del Flash Player 10), crear barras de scroll, etc. Además, los proyectos pueden ser vistos por medio del Flash Player o a través de Adobe AIR.

¿Catalyst indica el final de Flash?

Nada más alejado de la realidad. Al parecer, todo esto apunta a un malvado y secreto plan para conquistar el… err.. perdón, me desvié del tema.
Como decía antes, Catalyst está pensado hacia Flex, más concretamente hacia la nueva generación de Flex, cuyo nombre clave es Gumbo.
La intención es poder generar toda la Interfaz de Usuario en Catalyst, una más fácil y cómoda importación de animaciones de Flash en Flex y, al final, dejar este último para cosas más complejas como interacción con webservices u otras tecnologías/lenguajes de backend.
En ese sentido, Catalyst puede verse como un auxiliar de Flash, más que una competencia (hasta ahora no hay ningún indicio de que los archivos de Catalyst puedan ser editados en Flash y lo más probable es que así permanezca, al menos por ahora), dándole a cada aplicación una tarea específica en la creación/desarrollo de interfaces de usuario, pensando principalmente en RIA’s.

Ya Tenemos Flash ¿Necesitamos a Catalyst?

Está claro que si eres un pobre developer que cree que extra codicus nulla salus (fuera del código no hay salvación – Ramén) pensarás que sólo es una estratagema más para comprar productos innecesarios, pero eso es porque no piensas en el pobre diseñador, que debe sobrevivir con el sarpullido alérgico que le generan más de dos líneas de código, para quien gotoAndStop() es la entrada a un infierno de confusión y caos y que debe correr a solicitarte ayuda para lograr que su mundo vuelva al diseño, donde todo tiene sentido, donde está el cielo.
Si eres de esos no entenderás lo importante que es para el pobre diseñador mantenerse en el mundo de lo estéticamente correcto, de lo visible, de lo gráfico; nada de esas cosas locas llenas de letras y números que a ti te encantan y te hacen creer que eres importante y mereces lo que ganas ¡no!

Flash Catalyst promete librarte a ti, pobre y abnegado diseñador, de los dolores de cabeza que implican un onRelease o un alpha = 0.5, y lo hace del mismo modo que los behaviors en Flash o en Dreamweaver, pero mejor (esperemos que del lado del código también sea así porque he visto pocas cosas tan terribles como esos behaviors). Sólo debes seleccionar este objeto y convertirlo en un botón, este otro convertirlo en un scroll, seleccionar esto de más acá y hacerlo aparecer… todo con unos cuantos clicks sin ver jamás una línea de código y, si no necesita nada más complicado que eso, felicitaciones, has creado tu primera RIA!!!

¡Lo Quiero, y Ya!

No tan de prisa, zen.
Aunque ya ha cambiado de nombre (lo que siempre significa que ha evolucionado), Flash Catalyst aún no está disponible para descargas, habrá que esperar un poco. El mismo equipo de desarrollo habla de la beta pública para 2009, pero no especifica cuándo. De momento, puedes seguir estos vínculos para que te enteres un poco más de lo que se trata (quería embeber algún video, pero como ya se dieron cuenta en algunos blogs, el modo como los subieron en Adobe no lo permite, así que habrá que conformarse con los links):

• Flash Catalyst en Adobe Labs Mira los videos, tanto el del Diseño como el de Desarrollo.
• Demostración de Flash Catalyst para Adobe Edge – December 2008 (Boletín en línea de Adobe)
• Gumbo, What’s New?

Nota: Todos los links son en inglés, así que si no sabes inglés, al menos podrás ver los videos

Como colofón, un video sobre Catalyst, traído directamente de Adobe Tv (gracias, F):

(Pueden verlo más grande siguiendo este link: http://tv.adobe.com/#vi+f15383v1002)

Adobe en Vivo en Lima

La gente de Garage Flash, Adobe User Group de Perú y que han honrado anteriormente a este servidor publicándole un par de artículos presenta, este 30 de noviembre de 2008 su evento aniversario. En este caso se trata de Adobe en Vivo, que contará con la participación de un destacado staff de expositores nacionales e internacionales de muy alto nivel, lo que promete un gran evento. Ellos son:

• Luis Alarcón – Chile.
• Fernando Flores – Perú.
• María Eugenia Ballesteros (Mx) – Argentina.
• Raúl Jiménez (Elecash) – España.
• Edgar Parada – México.
• Freddie Vega (Freddie) – Colombia.
• Elder Vásquez (Eldervaz) – Perú.

Todos ellos estarán allí el 30, de forma gratuita. Además de eso, durante la semana algunos de ellos impartirán una serie de talleres (estos sí son pagos):

• Aprender a Usar Flash CS4 – Freddie Vega.
• Illustrator Enfocado al Diseño y Creatividad – María Eugenia Ballesteros.
• Planificación y Desarrollo de Proyectos con ActionScript – Elder Vásquez.
• Programación Modular en Flash Lite – Raúl Jiménez.
• Desarrollo de Aplicaciones en Adobe Flex – Edgar Parada.

Cada uno de estos talleres tiene una duración de 15 horas y tiene un costo de 400 soles peruanos (unos $129).
Por más que fastidié a Elder -y a pesar de sus esfuerzos- no será posible transmitir el evento vía connect o con cualquier otro servicio de broadcasting, puesto que la conexión a internet en el salón (Auditorio del Parque de la Amistad, Surco) es miserable o nula, pero sí me prometió que lo grabarían y luego lo pondrían online.
Si eres de Perú, Lima o alrededores, o alguna vuelta del destino te lleva por esos lados, no deberías dejar de asistir. Créeme cuando te digo que valdrá la pena; además, no es nada fácil tener a toda esta gente reunida en un mismo evento. Yo quería asistir, pero razones personales me retienen en Caracas, así que tendré que esperar al año que viene :S
Si quieres más información sobre las charlas, los talleres, las inscripciones, etc. no debes dejar de visitar www.adobenvivo.com o la página de Garage Flash, donde también hallarás información pertinente.
Si estás por ahí (hola Dientuki ^^) tómale una foto a Mx y me la envías *suspira

Adobe, Eventos, Desarrollo, Diseño, Charlas, Talleres, Perú, Lima

Adobe nos Muestra Creative Suite 4

¿Estás listo para algo brillante? Así comienza el registro para uno de los eventos más importantes del año en el mundo del diseño y el desarrollo web: La Presentación de Adobe Creative Suite 4.
Si en el MAX 2008 nos dejaron boquiabiertos con lo que entonces eran ideas para las próximas versiones de la suite, será más que interesante saber qué nos mostrarán ya implementado, además de el nuevo niño de Adobe: Thermo.
Es realmente extraño que en la web de adobe no haya mayor noticia al respecto y haya tenido que enterarme por Clab y por el blog de Pley, pero eso no quita que mañana será un día excitante para nosotros, minnions del Gran Ojo Adobe, y podremos, vía web, ver la presentación mundial de CS4.
Si quieres participar de la presentación, recuerda que será vía Connect, así que sólo necesitas conexión a internet y un navegador con Flash Player 9. En esta página puedes escoger la hora en la que quieres verlo y te enviará un recordatorio.
¿Y tú, estás listo para Algo Brillante?

Adobe, CS4, Web, Design, Development