Consejos para Enfrentar un Proyecto Web – Consideraciones Generales

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

Consejos para Enfrentar un Proyecto Web – Intro

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

MobileCamp en la Ciudad de México

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

What the Hell is “This”?

Después de escribir sobre el ámbito, me quedó en la mente la pregunta ¿por qué no hablaste del bendito “this”, que trae a todos los programadores que comienzan (y algunos que ya llevan tiempo) por el valle de la amargura? Así que, como no quería editar el post, preferí hacer uno nuevo.
Comencemos por el Principio:

¿Qué es “this”?

Pues simple, “this” es una palabra reservada en la mayoría de lenguajes de programación que tiene la particularidad de significar cosas diferentes según donde se encuentre. Es conocida también como una propiedad contextual.
¿Cómo es eso? La mejor forma que he encontrado para explicarlo es traduciéndolo al castellano. “This” significa “esto”.
Entonces, la particularidad de “esto” (que, si recuerdan un poco sus clases de castellano -cosa que seguro no pasará- es lo que se conoce como un adjetivo indicativo o determinativo (uhhhh, muy técnico o_Ô)).
En un sentido más llano, la palabra “esto” se refiere siempre a algo que está cerca, pero puede cambiar según el contexto.
Si estoy en esta habitación y digo “esto”, está claro a lo que me refiero (esta habitación), pero si salgo de ella y digo “esto” estoy hablando de algo completamente diferente… Es decir que lo que significa la palabra esto cambia dependiendo de donde me encuentre.
Exactamente lo mismo es lo que ocurre con this; su significado varía, dependiendo a donde se escriba.
Si estoy dentro de una clase, la referencia de this será esa clase, si estoy en un movieclip, en Flash, this se refiere a ese movieclip.
Es precisamente esta versatilidad de this la que causa grandes dolores de cabeza a muchos programadores, sobre todo cuando estamos comenzando, nos hallamos un poco perdidos cuando encontramos clases llenas de ella por todas partes y no entendemos de qué va.
Pues, la forma de resolver esa duda se basa en comprender el contexto donde la propiedad aparece (si es una clase, una instancia, una función…). Una vez que se comprende el contexto, se entiende fácilmente de qué se trata. Algo así como “para entender esto tienes que mirar alrededor”.
Así que, no tengan miedo de usarla. Bien usada es una poderosa herramienta que puede sacarlos de problemas y regalarles a cambio un código más limpio y más efectivo.

programación, desarrollo, this

Programación Orientada a Objetos – Ámbito, Public, Private, Protected, Local

Este post es parte de una serie de artículos sobre POO y viene a continuación de Sub Clases (II)

Bien, los temas que vamos a tratar en esta ocasión son tan básicos que posiblemente alguno piense ¿y por qué no hablamos de esto al principio? Y la respuesta lógica es: porque no lo habríamos entendido correctamente.
El tema que vamos a tratar ahora es uno de los mayores dolores de cabeza cuando se comienza con la programación -y más aún con la programación orientada a objetos-, muchos problemas en el código suelen estar asociados con algún error a nivel de ámbito, así que comencemos por allí:

¿Qué es el Ámbito y Cómo Afecta mi Vida Sexual?

Cuando hablamos de ámbito o alcance nos estamos refiriendo principalmente al área de influencia de una variable o función, a la zona donde ésta tiene sentido.

Toda variable/función tiene un rango de acción, se encuentra en un sitio, tiene un contexto, fuera del cual pierde significado y valor. Un ejemplo que puede ilustrar esto puede ser un lámpara. La lámpara, al encenderla, ilumina un área específica, pero no tiene influencia fuera de esa área. Por ejemplo: si necesito buscar algo en mi cuarto, que la luz de la sala o de la cocina estén encendidas sería irrelevante para mí porque mi cuarto está fuera del área que ellas iluminan, pero si enciendo la luz de mi cuarto puedo buscar lo que necesito más claramente, aunque no tendría ninguna influencia fuera de él, él ámbito (alcance) de esa luz se limita a mi cuarto.

De acuerdo con su ámbito una variable/función puede ser:

• Pública
• Privada
• Protegida
• Local

Vamos a hablar de estos ámbitos desde el punto de vista de la clase.

Public:

Una variable/función pública puede ser accedida desde fuera de la clase. Es decir, puedo acceder desde la instancia de la clase y no sólo desde el código interno de la clase. Ejemplo de funciones públicas son los métodos de una clase. También es posible crear variables públicas, para que puedan ser manejadas desde la instancia, pero no es algo común o recomendable, entre otras cosas porque deja un hueco de seguridad en la clase, acabando con la idea de la “encapsulación”. Para declarar una variable/función como pública, se le antepone la palabra clave “public”.

Private:

Al contrario que las públicas, las variables/funciones privadas sólo pueden ser accedidas desde dentro de la misma clase. Todo intento de llamarlas desde la una instancia de la misma es en vano. Mantener variables/funciones privadas permiten tener un mayor control sobre la clase, sobre el modo como procesa sus métodos, como maneja sus variables, etc. Para declarar una variable/función como privada, se le antepone la palabra clave “private”.

Protected:

Existe un tipo intermedio de ámbito, llamado “protegido”. Es un punto medio entre público y privado, porque -como ocurre con las privadas- no se puede acceder a ella desde una instancia de la clase, pero -como ocurre con las públicas- puede ser accedido desde las subclases de ésta, no importa si se encuentran o no en el mismo paquete. Básicamente significa que, si una clase hereda de otra, tendrá acceso a las variables/funciones protegidas de la super-clase, de lo contrario, no podrá acceder a ellas. Para declarar una variable como protegida, se le antepone la palabra clave “protected”.

Local:

Una variable “local” sólo es accesible desde dentro de la función donde se declara; esto es válido tanto para los parámetros de la función como para las variables declaradas dentro de ella. Una vez terminada la función, la variable es destruida hasta que la función vuelve a ser invocada. No hay palabras clave para las variables locales.

¿Cómo Afecta esto mi Vida Sexual?

Como dije, una buena parte de los problemas que la gente suele tener al trabajar con clases es comprender cómo funcionan los ámbitos, cómo acceder a funciones/propiedades/variables y como permitir a otros que accedan a las nuestras; por lo tanto, entender esto significa perder menos horas depurando código, lo que significa menos tiempo programando, lo que es igual a menos frustración por falta de tiempo para el sexo. Además a las chicas les encantan los buenos programadadores

Tags Technorati: POO, Programación Orientada a Objetos, Clases, Sub Clases, Ámbito