Qué es el Diseño de Interacción

Por Javier Velasco M.

Escrito Agosto 2004*, Publicado en mantruc.com Septiembre 2006

También disponible en Versión PDF (200 KB)

El diseño de interacción determina las posibilidades de operación de un sistema tecnológico: las posibilidades de acción de las personas que lo usarán, y las reacciones del sistema ante estas acciones.

Nociones básicas: Interacción e Interfaz

Comencemos por definir la interacción y la interfaz que nos mediatiza la interacción. La interacción es un diálogo de comportamiento entre dos entidades, el accionar de una condiciona la respuesta de la otra. De acuerdo al diccionario de la RAE:

interacción. 1.
f. Acción que se ejerce recíprocamente entre dos o más objetos, agentes, fuerzas, funciones, etc.
Real Academia Española ©

Todo sistema electrónico es interactivo, ya que modifica su comportamiento (funciones) de acuerdo a los comandos de un usuario.

La interacción entre un sistema y su usuario se canaliza a través de una interfaz o punto de encuentro. La interfaz hace tangibles las posibilidades del sistema y permite al usuario comunicar sus comandos al sistema.

interfaz. (Del ingl. interface, superficie de contacto).
1. f. Inform. Conexión física y funcional entre dos aparatos o sistemas independientes.
Real Academia Española ©

En los aparatos físicos, las interfaces se componen de perillas, botones, luces, pantallas, parlantes. En el software todo se debe canalizar a través de una interfaz doble: en primer lugar, está la interfaz del computador - dispositivos de entrada y salida, principalmente teclado, mouse, pantalla y parlantes - y en segundo, las interfaces del sistema operativo, generalmente compuesta de elementos como ventanas, directorios, menús, cursores.

El diseño de interacción y el diseño de la interfaz son mutuamente dependientes, muchas veces las decisiones de un plano condicionarán las decisiones en el otro plano.

Hasta el momento¹ , los sistemas electrónicos y tecnológicos en general, no están dotados de inteligencia propia. Todo sistema será tan inteligente como su diseño permita.

Dado que todo lo que puede hacer una máquina estará condicionado por su diseño, la tarea de diseñar su comportamiento consiste en prever las posibles acciones y respuestas de un humano ante este sistema, y diseñar reacción del sistema ante los comandos del humano. Se asemeja a crear la coreografía para un baile.

Antiguamente, los computadores tenían capacidades muy limitadas, esto significaba que el baile debía hacerse al paso de la máquina y que el usuario debía ser un experto en el lenguaje de la máquina, para ser capaz de seguirle el paso y lograr que ésta se moviera según su voluntad.

Actualmente, tanto el hardware como el software han evolucionado para ofrecer mayor flexibilidad en el diseño de cada función. Los usuarios de computadores actualmente son personas comunes que no poseen estudios en informática. Este factor hace más necesario crear coreografías más antropomorfas, donde sea la máquina la que siga el paso del humano. Ésa es la meta del diseño de interacción: crear sistemas que satisfagan las necesidades de las personas que los usan, en una forma que resulte espontánea y satisfactoria.

Quién se ocupa del diseño de interacción

Como ya se ha explicado, todo aparato tecnológico implica un diseño de interacción para poder ser operado por un usuario. Sin embargo, no todas las empresas que diseñan y construyen aparatos ó sistemas tecnológicos adoptan el diseño de interacción como un proceso particular, ni el rol de diseñador de interacción como un papel específico dentro de su equipo de trabajo. Muchas veces el diseño de interacción se realiza como parte de otros procesos, a veces a cargo de ingenieros y personas de negocios, otras veces como parte del aspecto ergonómico de los proyectos.

El diseño de interacción como actividad particular toma fuerza durante los años 90 con el crecimiento del área de la Interacción Persona-Ordenador (IPO / HCI) como una rama de las ciencias de la computación. Este crecimiento da origen a una serie de metodologías bajo el enfoque de Diseño Centrado en el Usuario.

Bajo un proceso ideal, es el diseñador de interacción quien creará las especificaciones para la construcción del sistema. Esto implica determinar las funcionalidades que ofrecerá el sistema, los parámetros para cada una de éstas, las secuencias de comandos necesarias para ejecutarlas y los elementos de la interfaz que permitirán a las personas manejar estas funciones, así como sus nombres, ubicación, tamaño relativo; y todos los elementos que canalicen la comunicación entre sistema y usuario, gatillos y mensajes.

Un ejemplo tangible

Para llevar todos estos conceptos abstractos a un plano más tangible, revisemos un caso común, con aparatos que usamos a diario. A continuación se analiza el comportamiento de dos equipos de sonido, de constructores diferentes, en una misma operación.

Nuestro breve análisis se basará en operaciones comunes a ambos equipos, el encendido y la selección de modo, función o fuente. Ambos sistemas ofrecen las mismas posibilidades en este sentido, sus modos son los mismos:

• Radio
• CD
• Cassette
• Entrada Auxiliar

En ambos casos, las interfaces han sido descritas en Inglés.

Equipo N 1

En este primer caso, vemos que el encendido opera únicamente a través del botón de encendido (Power). Esto implica que cualquier operación inicial con el sistema deberá ser precedida del uso de este botón. Cabe destacar que el botón de encendido ha sido diferenciado de los demás por una textura particular (tres puntos en relieve).

El equipo se enciende entonces en su modo anterior, el último que fue usado antes de ser apagado. Existe un botón único (Function) que permite cambiar el sistema de un modo a otro en un ciclo. Esto implica presionar el botón Function tres veces para pasar del modo Disc al modo FM.

Un análisis más exhaustivo de la interfaz nos revela que su distribución simétrica obedece más a criterios estéticos que de operación. Pero en esta instancia, nos centraremos exclusivamente en los comandos antes mencionados.

Equipo N 2

Nuestro segundo equipo también cuenta con el tradicional botón de encendido y apagado al que nos hemos acostumbrado (Power), pero además combina las dos funciones en cuestión al permitir su encendido a través de cualquiera de los cuatro botones de modo (o función). Esto implica una mayor flexibilidad de decisión para los usuarios, permitiendo eliminar un paso en su tarea; un usuario puede encender el sistema directamente en modo CD con sólo presionar el botón CD una vez.

La presentación de los modos de operación en cuatro botones paralelos e independientes, también otorga una mayor libertad de acción al usuario ya que no obliga a recorrer un ciclo para pasar de un modo al otro, como en el caso anterior en el que todo esto se hacía mediante un solo botón.

Al revisar la interfaz general, también se puede destacar que las dos funcionalidades analizadas se ubican en una posición predominante del tablero y se agrupan de manera lógica.

Este breve análisis nos da cuenta de cómo el enfoque o criterio utilizado durante el proceso de diseño afectará la experiencia del usuario. Las funcionalidades revisadas dan cuenta de dos procesos de diseño diferentes que dieron distinto grado de importancia a las necesidades de los usuarios.

Habiendo sido dueño y usuario de ambos sistemas por más de dos años, puedo dar testimonio personal a favor del segundo equipo de sonido. Estas pequeñas diferencias, sumadas a un diseño general más amigable, hacían del uso de este segundo sistema una experiencia considerablemente mejor que la del otro diseño.

Los santiaguinos de ojo inquisitivo se habrán dado cuenta que ambas fotos fueron tomadas sintonizando a Radio Concierto ¿qué esperaban? ;)

Un ejemplo Web

Hace algunos años, una tienda chilena de comercio electrónico presentaba la siguiente interfaz de búsqueda:

La interacción de este sistema está obligando al usuario a seleccionar al menos dos de sus opciones para poder realizar la búsqueda.

No permite hacer una búsqueda que cubra todos los precios, todas las marcas y todos los departamentos en la tienda. ¿Por qué no? ¿Será malo para el negocio dejar a sus clientes buscar en su base completa de productos?

Este caso nos permite ver cómo la interacción afecta la experiencia de usuario. En este caso, interrumpiendo el flujo de búsqueda por una restricción arbitraria del sistema.

Esto implica que durante este proceso de diseño particular, decisiones de negocio y limitaciones técnicas primaron por sobre la experiencia de usuario.

Jugando al diseñador

Para seguir haciendo más tangible estos conceptos tan abstractos, te invito a hacer un ejercicio:

Estamos trabajando en el diseño de un reloj despertador. Nuestro reloj será un dispositivo simple, sin funcionalidades complementarias, todo lo que necesita efectuar un usuario con el aparato es:

• Leer la hora.
• Configurar la hora actual.
• En caso de optar por un despliegue digital, se debe seleccionar el modo de despliegue: 24 horas, o ciclos de 12 horas AM y PM.
• Configurar la hora del despertador.
• Encender y apagar el despertador.
• Apagar la alarma.

Entonces, tú como diseñador deberás determinar las secuencias de acciones que permiten operar estas diferentes acciones, la cantidad, forma y tamaño relativo de los botones, palancas, selectores o perillas que permitirán elegir dichas funciones. Deberás definir los íconos o textos que permitirán al usuario comprender la utilidad de cada uno de estos elementos, así como las señales del sistema que dan a entender su modo actual de operación.

Metodología de diseño de interacción

El diseño de interacción comienza durante las etapas estratégicas del diseño, con la definición de requerimientos y funcionalidades, elementos claves que dan forma a la estrategia del sistema. Al hablar de diseño estratégico nos referimos a decisiones de negocios que permiten elegir una estrategia a tomar con un producto: estrategias de diferenciación de la competencia, audiencia primaria a enfocar el producto. El diseño de un producto tecnológico es un proceso complejo con múltiples dimensiones, estas decisiones estratégicas dan forma al producto, aunque muchas veces se las considere fuera del proceso de diseño.

Para crear un diseño amigable es fundamental entender a las personas que usarán el sistema, por esto parte importante de este trabajo consiste en entrevistar personas que representen al tipo de usuario final del sistema. Empaparse del modo de pensar, las necesidades y el lenguaje de los usuarios permitirá al diseñador estar en mejor pie para anticipar sus expectativas y reacciones, generando una interacción natural para ellos.

Alan Cooper, uno de los principales impulsores del método de diseño mediante personas y escenarios, explica que los ingenieros corresponden a un tipo distinto de humano – homo lógicus – que tiene una fuerte inclinación a la racionalidad. Esta racionalidad los inclina a aceptar todas las situaciones posibles al momento de diseñar un sistema, mientras que un diseñador dedicado – homo sapiens – que ha estudiado a sus usuarios, podrá enfocar el diseño en lo más probable. Este enfoque lleva a desarrollar una menor cantidad de funcionalidades, lo que implica que cada una de éstas podrá ser diseñada con mayor cuidado.

La principal ventaja del método de diseño con personas es que ayuda al equipo a enfocar sus energías en las necesidades de los personajes que se han definido. Al no definir claramente para quién estamos diseñando, cualquier característica y capricho que se pueda imaginar de los usuarios es creíble.

Existe una variedad de enfoques y métodos para guiar este proceso, algunos más formales, otros más flexibles. Algunos de estos modelos presentan un enfoque basado en la ingeniería, otros son más antropológicos.

Algunos procesos y herramientas de diseño de sistemas son:

• RUP, Racional Unified Process / UML
• XP, Extreme Programming
• Personas y Escenarios
• Prototipos de Papel
• Análisis de tareas
• Ingeniería de Usabilidad
  

Interacción en Web

En el caso de la Web (HTML), la interfaz se limita al trabajo con una plataforma restringida a páginas y con un número restringido de opciones para el input humano en la interacción:

• Links
• Formularios
  • Líneas o cajas de texto
  • Botones
  • Menús pull-down
  • Radio buttons
  • Checkboxes

Una interfaz restringida a páginas significa que cada paso que da el sistema en la interacción requiere del cambio de la página completa. Esta restricción ha permitido a los diseñadores plasmar la actividad de sus sistemas en diagramas de página o Wireframes.

Aplicaciones Ricas de Internet

Las limitaciones interactivas del lenguaje propio de la Web han representado tanto una ventaja como una desventaja para quienes diseñan interacción para este medio. La ventaja es que utilizan un lenguaje estandarizado que permite a los usuarios entender inmediatamente las posibilidades interactivas de cada elemento. La desventaja para los diseñadores es que pone límites muy restringidos a las posibilidades de interacción del sistema y encasilla su creatividad.

Los diseñadores han intentado desde los comienzos de la Web romper con las limitaciones del HTML y crear interfaces más flexibles. Sin embargo, estas interfaces de flexibilidad interactiva mayor no han podido ser estandarizadas en un 100%, y parte importante de éstas implican alguna tecnología propietaria ó plugins (javascript, flash, java, Ajax). Estas aplicaciones ricas permiten implementar funcionalidades web con una interacción más flexible, similar a las aplicaciones desktop. Bajo estos sistemas, la metáfora de la página se diluye, y los Wireframes se hacen insuficientes para documentar los diseños.

Para profundizar en el tema, pueden revisar:

• Ajax: A New Approach to Web Applications by Jesse James Garrett
• HTML’s Time is Over. Let’s Move On. by David Heller
• Usability Heuristics for Rich Internet Applications by Jess McMullin and Grant Skinner
• The Information Architecture of Things - Part I: What If a Button Really Is a Button? (DOC) - Bill DeRouchey
• The IA of Things, Part Two: Twenty Years of Lessons Learned (DOC) - James Leftwich
• Understanding Interaction Design (PPT) - David Heller
• Beyond the Page (PPT) - Gene Smith

1 - Ray Kurzweil, quien lleva más de 30 años estudiando sistemas de Inteligencia Artificial, afirma que los computadores alcanzarán y superarán de manera inevitable la inteligencia humana por el año 2030. Entonces podrán comenzar a diseñar nuevos sistemas más inteligentes que ellos mismos. Kurzweil plantea esto en su libro The Age of Spiritual Machines, la base teórica se puede encontrar en Internet en su “Law of Accelerating Returns”. (Volver al texto)

Nota de la Edición: Este artículo fue escrito originalmente el año 2004 para el sitio web de AIChile.org. Dado que nunca fue publicado en dicho sitio, ahora lo rescatamos de los archivos para publicarlo en mantruc.com

Fuente: http://mantruc.com/publicaciones/diseno-interaccion.html

De PSD a HTML/CSS - Maquetación

Nettuts en mi opinión es uno de los mejores portales sobre tutoriales de desarrollo web. Excelente todo lo que postean.
Muy interesante este:
http://nettuts.com/site-builds/from-psd-to-html-building-a-set-of-website-designs-step-by-step/

Mega post de Vectores, Brushes, Patterns, Photoshop

Creo que debe descargarse este espectacular post.

http://www.taringa.net/posts/downloads/1153152/Mega-post-de-Vectores,-Brushes,-Patterns,-Photoshop-II.html

LavaLamp for jQuery lovers!

Creo que no hay que perder este enlace. Fantastico tutorial sobre LavaLamp una extensión para jQuery. Realización de un menú dinámico:

http://www.gmarwaha.com/blog/2007/08/

Video seminario sobre PHP

Esta vez espectacular los videos sobre PHP de Luis Almeida. Me encanta los consejos que da y de la forma que lo dice.
Desde aqui podeis acceder a estos videos:
http://www.dominaphp.com/seminario.php

Merece la pena subirlos a otro sitio, cosa que haré en breve para que no se pierda esta reliquia y como más fuentes haya mejor.

Mejores libros sobre desarrollo web

Aqui tienes una selección de los mejores libros sobre desarrollo web que la comunidad NetTuts ha elegido:
http://nettuts.com/web-roundups/the-best-web-development-books-as-voted-by-you/

Metodología para el desarrollo de aplicaciones orientadas a objetos - Franco Díaz

La programación orientada a objetos requiere un profundo conocimiento y unas bases sólidas. Sí, puedes programar con orientación a objetos sin tener esos undamentos bien consolidados, pero tu curva de aprendizaje será mucho más lenta y no entenderás porque se hacen ciertas cosas.
Recomiendo la lectra de este libro:

Metodología para el desarrollo de aplicaciones orientadas a objetos - Franco Díaz

Te lo puedes descargar aqui:
http://rapidshare.com/files/114461334/poo.rar

Tecnicas para crear wallpapers espectaculares

Para los amantes de photoshop. La red está plagada de cosas y nadie va a venir a la mesita de tu ordenador a decirte hay esto y ta otro en internet que te puede interesar. Aunque ya vendrá eso...
He encontrado un ebook espectacular que por el momento no he sabido descargar. Se trata de un libro sobre la creación de formas raras con photoshop.
Si no sabes como crear esas formas que muchas veces ves en wallpapers y estas intigrado en hacerlo aqui tienes este pequeño pero interesantisimo ebook:
http://issuu.com/nytryk/docs/photoshop/5?mode=embed&documentId=080917090730-52ff955785014a888c7ef9853a911d16&layout=grey

Y hablando de wallpapers recmiendo mirar el software Ultra Fractal para realizar formas estramóticas y de enorme belleza.

** No hace falta ni mencionar que estas dos tecnicas las podemos aplicar en multitud de otras cosas que no san wallpapers. Comopor ejemlo de fondo de nuestro sitio web, del header de nuestro sitio web, etc...

Funciones anónimas y autoejecutables en javascript

¿Sabías que en javascript una función puede contener a otras? Pues ahora ya lo sabes. Fíjate en el siguiente código:

function barrioSesamo() {
  function epi() {
      alert('hola Blas');
  }

  function blas() {
      alert('hola Epi');
  }

  epi();
  blas();
}

barrioSesamo();
// el navegador nos presentará un par
// de alertas, a saber, "hola Blas" y
// "hola Epi"

Nada impresionante, por el momento. Lo interesante del asunto es que, al definir la función epi dentro de la función barrioSesamo, el ámbito de la misma (scope) queda limitado, de manera que solo podemos llamar a epi desde su propio barrio.

Vale, sigo sin impresionarte. ¿Qué ganamos al definir funciones de esta manera? Al limitar el ámbito de la función, evitamos colisiones con (posibles) funciones del mismo nombre (posiblemente) definidas en otro(s) script(s).

Veamos ahora eso de las funciones anónimas:

function() {
  alert('soy la función sin nombre');
}

Queda claro: una función anónima es… efectivamente, una función que no tiene nombre. Y si no tiene nombre, ¿cómo demonios hacemos una llamada a la misma? Truco: haciendo que se ejecute por su cuenta.

(
function() {
  alert('me ejecuto yo solita');
}
)();

Fíjate bien en la sintaxis: la función va definida entre un par de paréntesis, a continuación de los cuales viene otro par, que utilizamos para ejecutar la llamada.

¿Aún impasible? Eres duro, tío. Quizá la traca final consiga impresionarte:

(
function() {
  function hazCosasMaravillosasConElDOM() {
      // lo que fuere
  }

  //addEvent() by John Resig
  function addEvent( obj, type, fn ){
      if (obj.addEventListener){
          obj.addEventListener( type, fn, false );
      }
      else if (obj.attachEvent){
          obj["e"+type+fn] = fn;
          obj[type+fn] = function(){ obj["e"+type+fn]( window.event ); }
          obj.attachEvent( "on"+type, obj[type+fn] );
      }
  }

  // la función comienza a ejecutarse
  // en la próxima línea
  addEvent(window, 'load', hazCosasMaravillosasConElDOM);
}
)();

¿Lo pillas? Ahora tenemos un script completamente encapsulado, que se ejecuta él solito y que jamás de los jamases colisionará con otros scripts con los que le toque convivir.

El colmo de la no intrusividad.

Fuente:
http://dizque.lacalabaza.net/sotanos/2006/05/funciones-anonimas-y-autoejecutables-en-javascript/

Readernaut

Readernaut es parecido a una red social sobre libros de todo tipo, en la que puedes consultar opiniones de otros usuarios para así si finalmente decides que vale la pena comprar ese libro te redirige a Amazón.
http://readernaut.com

Cache Buster - Refresco para maquetadores CSS

Todos los que maquetamos tenemos este problema. Firefox guarda en cache el CSS y no nos muestra el que acabamos de editar. Una solución es utilizar el FIREBUG o WEB DEVELOPMENT, pero para cuando no lo usuamos porque no nos va bien, aqui tenemos este script de JavaScript.

javascript:(function(){var%20s,i,x;x=document.getElementsByTagName('link');for(i=0;i

Este es el link:

Cache Buster

Guardalo como un link normal en tus favoritos del navegador para tener a mano y poder apretarlo cada vez que quieras refrescar correctamente tu pagina.



Web oficial del Script:

http://www.jasongraphix.com/archive/2007/08/css_cachebuster

Scripts RSS

Muchos paquetes de scripts orientado a recoger RSS. Muy bueno.
http://www.feedforall.com/download.htm

825 links para desarrolladores

recopilación de más de 825 links para desarrolladores y diseñadores:
http://3kolone.org/bookmarks.php

Cuando lo gráfico nos distrae: el dilema de diseñar interfaces

Hace unos días fuimos el equipo de diseño interacción a presentar un proyecto final con nuestro cliente. Era una propuesta de arquitectura de información y diseño de interfaces touchscreen. En esta presentación nos encontramos con el equipo de diseño gráfico y desarrollo quienes al observar que nuestra propuesta no presentaba (o no pretendía recomendar) iconos o imágenes que acompañaran la navegación, hizo que se generara cierta polémica.

Por acá les comparto algunas recomendaciones que creo se deben tomar en cuenta cuando diseñamos interfaces para medios no tradicionales.

Para empezar…

En nuestra investigación de usuario detectamos que el uso de nuestra interfaz se dirigía a gente que sabía leer y que tenía poco apego a la tecnología. Es decir, podían leer instrucciones sencillas y habían usado alguna computadora para tareas básicas (pero siempre con la ayuda de algún familiar o amigo). Sin embargo pese a esos hallazgos el equipo de diseño de nuestro cliente pedía que la interfaz pudiera ser entendida por gente analfabeta (primer error) y que utilizara un teclado en pantalla estándar (ejemplo: QWERTY) para introducir datos (segundo error). Lo cual sonaría lógico de primera impresión, pero tras hacer pruebas con usuarios reales solo haría que nuestra interfaz fracasara tanto para el público deseado como para el usuario real.

Al final me dio la impresión que el equipo de diseño, antes de crear nuevos lineamientos para este tipo de interfaces en su manual de identidad corporativa, hará cambios a nuestra propuesta (tercer error).

Por estas razones recomendaría lo siguiente a todos los equipos de diseño y desarrollo interesados por mantener estándares gráficos y efectivos en todos sus medios o canales de comunicación:

Observa a tus usuarios finales

Ahórrense horas y horas de discusión hipotética entre diseñadores, creativos, directivos, etc. Mejor aprovechen ese tiempo para observar e interactuar con sus usuarios finales, ellos les dirán lo que necesitan. Y ustedes les facilitarán el medio y la tecnología.

Evita decorar interfaces

Es cierto que las imágenes, iconos e ilustraciones son de mucha ayuda para comunicar mensajes, pero empieza por lo básico: jerarquía de información, depuración de datos, diagramas de flujo, estructuración de contenidos, redacción de textos. A muchos no les gustan esas fases del proceso, pero eso también es diseñar. De hecho esto no sólo aplica para cuestiones de diseño de interfaces sino a cualquier proceso de diseño.

Contextualiza

Siempre ubica tu solución de diseño en su contexto o entorno real, no solo en tu computadora, en tu despacho o en la oficina del cliente. Igualmente contextualizar está ligado a comparar tu solución con productos con atributos semejantes; no es lo mismo diseñar iconos para las terminales del metro (un medio de transporte), que iconos para interfaces touchscreen.

Los manuales de identidad deben estar en constante cambio

Tal vez el manual de identidad de tu empresa nunca contempló que la internet nacería y mucho menos que las interfaces touchscreen serían utilizadas dentro de los canales de comunicación con sus clientes o usuarios. Si la empresa en la que trabajas usa esas tecnologías, no dejes que los lineamientos de diseño editorial rijan esos canales, si eso llega pasar, el fracaso será evidente y adivina a quién le echarán la culpa.

No diseñes para todo el mundo

Diseña para tus usuarios finales reales. Hacer que nuestro diseño pueda ser usado y entendido por TODOS no siempre es el mejor camino, pero si un camino rápido para que tu interfaz fracase.

Estos son algunos puntos que me vinieron a la mente que debemos tomar en cuanta para el diseño de interfaces efectivas. Muy generales porque tampoco pretendo hacer toda una lista de criterios, al mero estilo de evaluación heurística, pero creo que antes de seguir lineamientos de usabilidad, se debe comprender el por qué se hacen las cosas y con qué finalidad.

Fuente: http://alquimistas.evilnolo.com/2008/08/11/el-dilema-de-disenar-interfaces/#more-484

Guía para iniciar un proyecto

Fuente del artículo: http://perlenespanol.baboonsoftware.com/articulos/archivo/000102.html

Estaba sentado frente a mi laptop pensando en que escribir, y aunque no lo crean hay veces que no se me ocurre nada. Sin embargo por alguna extraña razón mi mente empezó a recordar todos aquellos proyectos que empece y como ha evolucionado la manera en que los hago, todo esto me dió la idea de hacer un tutorial donde les mostraría más o menos la técnica que uso para crear un proyecto.

Hay diversas razones por las cuales uno decide iniciar un proyecto, ya sea por un trabajo, una tarea, o simplemente porque uno esta aburrido y quiere investigar lo que es capaz de hacer. Pero no importa cualquiera de estos casos siempre tenemos que seguir un lineamiento, unas reglas o formato sea cual sea con el cual plantearemos lo que queremos hacer.

Después de años de trabajar he llegado a usar un sistema que me sirve muchisimo y con el cual se me es más fácil trabajar y a continuación se los muestro ya separado por pasos.

PASO 1 : Ideando lo Ideal

Aunque parezca tonto o incluso rídiculo el primer paso es...tambores por favor...SABER LO QUE QUEREMOS HACER (por favor disculpen mi poco sentido del humor).

No se rían pero es cierto, dejen les éxplico un poco, al inicio de mi vida como programador me encontraba escribiendo código y a las 1000 lineas de código me decía, ¿qué es lo que hago? ¿por qué no mejor hago esto o tal cosa?, era una lamentable pérdida de tiempo, y todo eso porque no medite un poco y pense en lo que quería hacer.

Es por ello que les digo que el primer y muy importante paso, es idear lo que queremos, yo hago eso respondiendo preguntas como ¿qué? ¿por qué? ¿cómo? ¿para qué?, etc.

Como soy un amante de los ejemplos para este artículo vamos a suponer que una compañía de seguros nos contrata para hacer un CGI en línea que saque presupuestos del costo de los seguros siguiendo una serie de preguntas que se les haría a los clientes. Sabiendo esto ya tenemos las primeras respuestas de ¿qué? y ¿para qué?, estamos en un bueno comienzo y nos lleva al segundo paso que es decidir que es lo que vamos a usar.

PASO 2 : Herramientas

En el paso anterior ya vimos el planteamiento inicial del problema, ahora es necesario ver que herramientas necesitamos para solucionarlo y si somos capaces de hacerlo o si necesitaríamos aprender algo nuevo.

NOTA: Algo importante que he aprendido es siempre conocer bien tus límites, nunca te metas en proyectos que al final podrías acabar no haciendo, o peor, haciendo mal.

En este caso hagamos la lista de cosas que tendríamos que saber y que utilizaríamos.

HTML Debido a que quieren hacer un CGI es necesario que sepamos HTML para el diseño. Javascript Quizá lo necesitemos para checar formas, etc. MySQL,Oracle,Postgres Vamos a necesitar un database para ordenar todo los datos. (Costos, tipos de seguros,etc). Perl Por supuesto que debemos de conocer nuestro lenguaje de programación sea cual fuere el que queremos usar. DBI Debemos de saber como comunicarnos a nuestro database, en el caso que usemos perl ó C++.

Pues listo, ya tenemos nuestra lista de conocimientos necesarios para encaminarnos a nuestro proyecto, y sabemos que cumplimos con todas las necesidades.

NOTA: Para proyectos más complejos es necesario hacer una lista de conocimientos del propio lenguaje de programación.

Bien ya tenemos nuestra siguiente pregunta respondida ¿cómo?, ahora pasaremos al siguiente paso.

PASO 3 : Estructura

Muy bien ya que tenemos todo lo anterior anotado ahora veamos lo que sería la estructura ya más formada de nuestro proyecto, es decir es hora de escribir todas las funciones que tendrá nuestro proyecto, por ejemplo para este caso sería algo así:

1. Capacidad de checar presupuesto de seguros
2. Mecanismo de búsqueda
3. ... etc

Así vamos llenando la lista con todas las cosas que queremos que nuestro programa haga, yo recomiendo que en este paso piensen realmente en todas las opciones, para que al estar en medio del proyecto no salga algo que se les haya olvidado.

PASO 4 : Interface

Siempre después de tener ya muy en claro lo que quiero lograr con el proyecto, lo primero que hago es la interface, y esto lo hago debido a dos razones:

1. Te permite definir mucho más la estructura general del proyecto debido a que tienes que hacer los menús, cada una de las páginas, ya sean formas, mensajes de error, etc. Simplemente te hace pensar en todas las posibilidades.

2. Al tener la interface lista tienes mucho más definido el orden en que tienes que ir haciendo el programa.

A parte de todo esto, lo que hace la diferencia entre un buen CGI y uno malo fácil en un 70% es la interface, pues esto va a marcar si va a servir para el usuario y si es cómodo y sencillo usar tu CGI, recuerda en pensar siempre en tus usuarios al hacer tu CGI, especialmente cuando haces CGIs que usarían personas que no estan acostumbradas al internet o a las computadoras en si.

PASO 5 : Estilo de programación

Antes de inciar a hacer el código tienes que hacer un especie de contrato contigo mismo para decidir de que manera vas a escribir tu código. Este paso es realmente importante pues va a marcar la diferencia entre un código fácil de mantener y entender a uno que no lo es.

Lo primero que debes de decidir es si tu aplicación la vas a hacer modular o en un gran archivo, para que me haga a entender mejor: el modular es cuando separas las funciones en pequeños módulos para así hacer una librería, por ejemplo en este caso podríamos hacer un módulo llamado "Matematicas.pm" que tendría todas las funciones relacionadas a operaciones matemáticas; en el otro caso pones todas las funciones un un archivo grande exceptuando, como es lógico, a módulos de perl ya existentes.

Mi recomendación en este caso depende del caso: si va a ser un código de muchas líneas, digamos más de 3 ó 4 mil, lo más seguro es que quieras separarlo en módulos lo que lo haría más fácil de mantener, aparte de que así recordarías mejor cada función.

En segundo lugar antes de iniciar es importante que decidas de que manera vas a escribir tus variables, hay varias maneras de hacerlo y aquí pongo unos ejemplos:

my $costoTotal; #Todo junto con cada palabra separada por una mayúscula
my $CostoTotal; #Mismo que arriba pero iniciando con mayúscula
my $costo_total; #Palabras separadas por _
my $Costo_Total; #Igual que el de arriba pero con mayúsculas

Estos son apenas unos ejemplos, pero no importando el estilo es sumamente importante que te mantengas a él para tener un código mas limpio. También es sumamente importante que el nombre de las variables sea descriptivo del contenido que tienen.

En tercer lugar siempre que nombres tus funciones dales un nombre que al verlo te haga entender lo que hace esa función. Funciones llamadas suma, resta, despliegue, etc. evítalas, mejor decide por suma_intereses, resta_operaciones, despligue_encabezado_html, etc.

En cuarto lugar siempre usa el pragma strict al hacer tus programas.

Quinto: Nunca olvides usar la función exit() para salir del programa.

Y por último siempre pon comentarios en todas partes, estos te servirán como guías cuando 1 año después veas tu código nuevamente.

Sigue todos estos puntos y tu código quedará sumamente limpio y muy fácil de mantener inclusive por terceras personas.

PASO 6 : Las Pruebas

Al terminar tu código recuerda siempre hacer pruebas, lanza tu programa en versión BETA y pide a varias personas que lo exploren, que intenten que falle, has la lista de cosas que fallaron corrígelas y vuelve a hacer el proceso, has esto hasta que ya no encuentres un error.

Nunca va a quedar tu aplicación perfecta e inmune de errores, pero intenta que haya el mínimo de errores posibles.

PASO 7 : El Soporte

Quizá sea buena práctica que hagas módulos de ayuda para tus aplicaciones, explicando como funciona, que es lo que uno tiene que hacer, etc. Aunque esto no afecta la aplicación en sí, podrías empezar a acostumbrarte a ello, creéme mucha gente lo apreciará.

CONCLUSIÓN

Les aseguro que podría haber mejores maneras de diseñar tu proyecto, pero estos pasos me han ayudado en la creación de proyectos, pequeños, medianos y de gran escala, pero de lo que no hay duda es que para hacer un buen proyecto necesitas planeación, planeación y más planeación.

Espero que esta artículo les ayude a mejorar sus costumbres de programación y los lleve a hacer aplicacines mas robustas y mejores.

Fuente del artículo: http://perlenespanol.baboonsoftware.com/articulos/archivo/000102.html