Archivo para la categoría Diseño
El chiste del ingeniero, el físico y el matemático
Escrito por Leonel en Diseño, Ingeniería el Enero 5th, 2010
Un granjero desea averiguar el volumen de una vaca
He recibido chistes de ingenieros varias veces por email y seguramente quienes leen esto conocen algunos más (y apuesto que un mayor número sobre abogados, creo que… ¡ellos se lo buscaron!). Pero hubo uno que me enviaron que me gustó mucho porque en mi opinión refleja de forma bastante exacta algo que podríamos llamar el sentido práctico que nos caracteriza.
Un ingeniero, un matemático y un físico llegan de visita a una granja y el granjero les pide que midan el volumen de una de sus vacas.
El ingeniero llena de agua un depósito, mete a la vaca dentro, mide el volumen de agua desplazado y da la respuesta.
El matemático construye un modelo parametrizable en base a la altura del bovino y distancia desde la cabeza a la cola, hace un programa en C++ y lo presenta al granjero como solución general con la que puede averiguar el volumen de todas las vacas que quiera con un error de sólo 5%.
El físico inicia su razonamiento así: “supongamos que la vaca es esférica…”.
Claro, es un chiste, y de ninguna manera se puede asumir que corresponde exactamente a la realidad, pero me parece que refleja muy bien la formación y preparación que cada profesional recibe.
El ingeniero sumerge la vaca y mide el volumen de agua desplazado
El ingeniero está constantemente resolviendo problemas concretos y particulares. Por ejemplo, un edificio, una carretera, un sistema informático, una planta de procesamiento, un vehículo o sumergir una vaca en un depósito para medir su volumen, son soluciones concretas a problemas particulares, ninguno soluciona de forma general el problema habitacional, de transporte, de proceso de información, de producción, etc. Físicos y matemáticos, por el contrario, buscan soluciones generales aplicables a todos los casos, probablemente con métodos y herramientas diferentes, pero similares en cuanto al objetivo.
La solución parametrizable del matemático resuelve el problema general
Un físico o un matemático podrían construir un edificio, lo mismo que un ingeniero podría desarrollar una teoría que funcionara como solución general a un tipo de problemas, pero no es lo usual ya que no es lo que corresponde a su preparación.
El físico inicia su razonamiento diciendo: supongamos que la vaca es esférica...
En conclusión, este chiste, como muchísimos más nacidos del ingenio y chispa humanos, contiene una percepción bastante acertada acerca de ingenieros, físicos y matemáticos.
De bitmaps a vectores
Escrito por Leonel en Diseño, Ingeniería el Diciembre 11th, 2009
Se parte de un dibujo bitmap normal
La mayoría de imágenes disponibles en Internet son mapas de bits o variantes de ese formato (jpeg, gif, tiff, png, etc). Un mapa de bits almacena la información de color punto por punto, al final la imagen se forma colocando los puntos juntos como una pintura puntillista, y la percibimos como continua porque al ver mezclamos los puntos y colores por proximidad.
Estas imágenes no son tan buenas cuando se intentan ampliar (hacerlas más grandes), porque se distorsionan hasta llegar a un punto en el que se ven borrosas, difusas, cuadriculadas o “pixeladas” como cuando uno mira de cerca un mosaico.
Los bitmaps no funcionan muy bien cuando se necesitan agrandar o reducir
Si se necesita ampliar o reducir las imágenes es mejor convertirlas a un formato de vectores, compuesto por líneas y otras figuras geométricas que contienen la información para reconstruirlas sin importar la escala. Por ejemplo, un triángulo rectángulo de base 10 y altura 5, si se aumenta al doble de tamaño debe resultar en un triángulo de base 20 y altura 10. Ambas figuras pueden dibujarse sin ninguna distorsión, porque la información de forma y dimensiones va almacenada en la definición de la imagen.
No siempre es posible convertir de mapas de bits a vectores. Hay diferentes herramientas que lo hacen automáticamente, usando técnicas de reconocimiento de patrones por ejemplo. Los resultados que producen pueden variar en calidad y sobre todo, difieren en criterio de vectorización. En algunos casos se obtendrá una reconstrucción más detallada y fina y en otros una más burda.
Con una línea y la herramienta "Modificar puntos" se puede reconstruir la imagen
Como casi todo mundo tiene Power Point instalado en su computadora (en Windows y en Mac, y existen programas similares en Linux) una técnica simple para convertir una imagen mapa de bits a vectores consiste en dibujar una línea recta sobre el original y luego usar la herramienta “Modificar puntos” para ir colocando puntos sobre las líneas identificadas en el dibujo original.
Resulta un trabajo muy entretenido – es similar a tejer – aunque es recomendable realizarlo con un mouse que sea cómodo y que no fuerce la mano o la muñeca.
He utilizado esta técnica en múltiples ocasiones para obtener imágenes vectorizadas de las que pueda disponer para diversos propósitos. El caso más reciente es el del fan-fic “Harry Potter y la brujita bloguera” en el que tomando como base imágenes del mago y sus amigos (en estilo “anime”) se crearon sus equivalentes vectorizados sobre los que fue muy sencillo crear expresiones faciales con solo cambiar rasgos como la boca, el ceño, el tamaño de los ojos, etc.
También lo he utilizado para digitalizar logotipos, cuando sólo se dispone de una versión “escaneada”, luego estos se pueden utilizar para crear animaciones por ejemplo. De hecho se pueden ver algunos ejemplos en la página de animación de logotipos de Ingeniería Simple, siendo el único producto que se vende en el sitio – de momento.
Una vez se dispone de la imagen vectorizada, cambiar la expresión, la mirada o el gesto, requiere sólo de unos cuantos trazos digitales
Las ilustraciones de “Harry Potter y la brujita bloguera” están disponibles en la página de Harry Potter en Ingeniería Simple.
Los mejores ingenieros
Escrito por Leonel en Diseño, Ingeniería, Trabajo en equipo, Usabilidad el Septiembre 8th, 2009
Todo proyecto de ingeniería debe tener un diseño
Sería un tanto pretencioso decir que hay ciertas características bien identificadas que definen a los mejores ingenieros, sobre todo porque cuando se presentan circunstancias especiales – como catástrofes, emergencias o problemas muy difíciles – los factores de peso pueden ser múltiples. Sin embargo, como se verá más adelante, existen cuatro virtudes que marcan una diferencia tan palpable que no es posible ignorarlas y en particular hacerlo en la formación de los futuros ingenieros trae consecuencias negativas.
La fórmula para “formar” a los mejores ingenieros del mundo parece sencilla: matemáticas, física, química, todas de buen nivel, cursos exigentes en el área técnica y profesional de la rama y un complemento que cubra las principales habilidades de gerencia y administración que tan necesarias resultan para el trabajo en el mundo empresarial actual.
Pero esa fórmula tiene un fallo: no ayuda por sí misma a obtener ciertas habilidades para las que la clave no es el contenido formativo, sino la práctica constante, el enfoque de los ejercicios, las situaciones a las que como parte de cada curso se expone a los alumnos, etc.
Sin más, esas cuatro virtudes o habilidades especiales tan deseables en un ingeniero son: el trabajo en equipo, cuidado por la seguridad, respeto por el usuario y pasión por el diseño. Ninguna puede considerarse más prioritaria que otra, puesto que usualmente son inherentes y concomitantes a cualquier proyecto.
El trabajo en equipo ni siquiera es una opción en ingeniería
Trabajar en equipo en ingeniería ni siquiera es una opción, pero que siempre se tenga que hacer no significa que siempre se haga bien. Hay mejores formas de trabajar en equipo y hay vicios que se le oponen directamente, como el protagonismo individualista, la inconsistencia en la planificación o en la definición de objetivos, las fallas en la comunicación, etc.
Muchos ingenieros deben aprender a trabajar en equipo en su vida profesional – por no haberlo aprendido en sus años de formación en la escuela de ingeniería – y mejorar cada vez más en ese aspecto a costa de perder eficiencia si no lo hacen.
Pero esa no es una opción en materia de seguridad donde las omisiones y negligencias pueden resultar en graves pérdidas económicas o humanas.
El mejor ingeniero en seguridad es el que la tiene presente a partir del mismísimo inicio de cada ciclo de ingeniería, desde el planteamiento de un proyecto, pasando por sus etapas de análisis y diseño, el respeto por las normas establecidas de seguridad y el recurso a principios más generales cuando las buenas prácticas no están bien identificadas, es lo que garantiza una solución segura para los usuarios finales.
En último caso, los riesgos no cubiertos, por cualquier razón, deben quedar claramente consignados en la documentación del proyecto.
Por tanto, la seguridad en ingeniería debe ser también un hábito del ingeniero. Ahora bien, la adquisición de un hábito puede hacerse en los años de formación, en ambientes donde los riesgos se controlan mejor, o puede hacerse en el ejercicio profesional con lo que el costo del aprendizaje corre por cuenta de los usuarios finales. Obviamente es mejor crear el hábito en los años de formación.
Pero esto no se logra si la seguridad se confina en la formación a uno o varios cursos independientes del resto – que usualmente se colocan al final de la carrera – como si la falta del hábito de la seguridad pudiera subsanarse con puros conocimientos teóricos. Es mejor que en cada proyecto, sin importar el curso o el contexto en el que se ejecuta, se exija al estudiante que cuide los aspectos de seguridad. Esta sí es una forma efectiva de crear el hábito. Requiere creatividad de parte de los catedráticos y evaluadores identificar los requisitos de seguridad en todo proyecto. Para encontrar indicios, se puede hacer la pregunta ¿qué tendría que tener este proyecto para no comprometer la seguridad de sus usuarios si fuera implementado en el mundo real?
Los productos de ingeniería tienen usuarios que merecen respeto
De la misma forma se puede promover el respeto por el usuario final. En buena parte de los cursos de ingeniería se pierde el interés por la usabilidad de los productos finales, probablemente porque se enfatiza la calidad técnica de la solución, es decir sus mecanismos internos de funcionamiento, su eficiencia en el proceso, el costo mínimo, etc. No es difícil olvidar que alguien será el usuario final de la solución y que la eficiencia técnica no sirve de mucho si el artefacto es imposible de usar, sin mencionar que el costo de soporte de un mecanismo complicado para el usuario se eleva hasta anular cualquier ahorro en su fabricación.
En relación al diseño pareciera una redundancia recalcar lo importante que es. Todo proyecto de ingeniería debería empezar su etapa de construcción con un diseño bien estructurado. El hecho de que no suceda así es indicativo de que algo falta para hablar de verdadera ingeniería.
Nuevamente el énfasis se traslada demasiado rápido al reto técnico de la construcción, con todas sus variables, materiales, tecnología y trabajo práctico y se obvia o disculpa el paso y la evaluación de un buen diseño, hasta convertirse en algo habitual, es decir, un vicio, el vicio de no diseñar.
Más que inculcar el hábito lo que la escuela de ingeniería debería lograr es despertar en el futuro profesional una pasión tal por el diseño que nunca pueda plantearse ni remotamente empezar una etapa de construcción sin un diseño bien definido.
Imagine Cup 2009, Un Par de Días Más
Escrito por Leonel en Diseño, Imagine Cup el Mayo 29th, 2009
Foto de un cerro tomada en el parque de Santa Elena Barillas, Villa Canales, Guatemala. Esta foto abre el video que envié a Imagine Cup.
Envié mi presentación para la ronda 2 de Imagine Cup apenas una hora antes de que cerrara el plazo el pasado 20 de mayo, la verdad sin muchas esperanzas. Con un poco más de tiempo creo que habría hecho algo mejor…
Revisando el forum de la competencia de diseño me di cuenta de que probablemente alguno de los otros 150 equipos participantes habría tenido el mismo sentimiento.
Comparado con la ronda 1, donde todo era creatividad, la ronda 2 resultó más complicada, había que hacer un video de 2 minutos, hacer varias descripciones en texto del proyecto y hacer un ejecutable usando alguno de los productos de Microsoft de la serie Expression, excelente software, pero llegar a conocerlo lo suficiente como para producir algo presentable resultó no ser tan fácil.
Los 2 minutos de video los fui llenando segundo a segundo y al final no quedó muy profesional. Dura un minuto con 58 segundos, no tiene música de fondo y la voz del narrador es la mía. Me consolé pensando que no se trata de un concurso de elaboración de videos sino de diseño, así que no se puede calificar en base a la calidad del video como tal sino por lo buena que pueda resultar la solución de diseño en sí misma.
En todo caso me alegro de que haya pasado la fecha, de haber enviado “algo” y de que ya el próximo lunes se acabe todo.
No me extrañaré si no paso a las finales – solo 6 equipos de entre los 150 finalistas de todas partes del mundo irán a Egipto para la final – así que lo que pase de eso será ganancia.
Llené el cuestionario que la organización solicitó a todos los que pasaron a la ronda 2 y lo dejé todo así.
Como recuerdo quedarán la página de mi equipo – LTOLT, un equipo de un solo miembro – la presentación que subí a SlideShare, y el video que puse en YouTube, estos dos últimos los tengo de acceso privado mientras no den los resultados, pero pienso hacerlos públicos cuando eso suceda.
Por supuesto saqué muchas cosas positivas de la experiencia, eso no puedo negarlo.
Un Concepto de Ingeniería
Escrito por Leonel en Diseño, Ingeniería el Abril 30th, 2009
Entender la ingeniería como actividad profesional es tan importante como estudiar y ganar las materias que sirven para graduarse de ingeniero. Hay muchas preguntas en la mente de la gente que requiere sus servicios y también en la de quienes se plantean estudiar una carrera universitaria.
Tres aspectos inherentes a la ingeniería pueden servir para definirla.
Ingeniería es: tener la ciencia para determinar dónde estámos - para analizar un problema -, poder diseñar la solución - explorar dónde nos gustaría estar -, y construir el camino que nos lleva de donde estamos a donde nos gustaría estar
El primero es el aspecto científico. El ingeniero tiene a su disposición herramientas que en general son comunes a investigadores y gente de ciencia pura: el método científico, las ciencias básicas – matemáticas, física, química, ciencias computacionales, estadística, etc. – el conocimiento acumulado que se publica en libros y revistas especializadas, congresos y conferencias donde se ponen en común experiencias y descubrimientos particulares, etc., todo ello le capacita para analizar problemas de diferentes disciplinas.
La segunda faceta del ingeniero es la de diseñador. Dado un problema específico a resolver se deben aplicar criterios, considerar opciones, decidir cuál es la más adecuada y especificar la estrategia para implementarla. Luego se deben atender a un sinfín de detalles de planeación y puesta en común con todos los involucrados, previos al inicio de la implementación de la solución. Todo ello es un proceso de diseño.
En la práctica de la ingeniería ningún problema es igual a otro. Aunque se disponga de soluciones aplicables en multitud de situaciones, siempre es necesario adecuar el diseño o rediseñar de acuerdo a las condiciones particulares. En esto se diferencia de la ciencia pura, que busca precisamente soluciones generales, aplicables siempre y que producen los mismos resultados consistentemente. Por supuesto esto no quiere decir que no sea posible hacer ciencia ingenieril, al contrario, las universidades y los centros de investigación producen ciencia en todas las ramas de la ingeniería, y ésta es utilísima al ingeniero, pero en el ejercicio profesional se requiere algo más que proviene del criterio, la experiencia, la intuición y otras cualidades.
Siempre he dicho que los ingenieros no atendemos lo suficiente a los aspectos estéticos del diseño. Por ejemplo, no es raro que un edificio diseñado por un arquitecto tenga mayor atractivo visual y espacial que el de un ingeniero civil, o que una página de Internet elaborada por un ingeniero de sistemas produzca una experiencia de usuario menos completa que la de un diseñador gráfico. Pero hay otros aspectos del diseño que no escapan al ingeniero: la eficiencia, la funcionalidad, la racionalidad, etc.
Por supuesto esto no quiere decir que no se deba mejorar la formación del ingeniero para que sus diseños sean más estéticos, al contrario, a mi me parece que esta es una seria deficiencia en muchas escuelas de ingeniería y que debe ser subsanada. Lo que quiero decir es que en el diseño ingenieril se da prioridad a lo ético sobre lo estético.
La tercera faceta es el trabajo de construcción y aquí el ingeniero se aparta del diseñador puro, a quien solo le interesa proveer la solución, el ingeniero quiere construir y no se conforma con solo diseñar.
En muchos contextos ingeniero y constructor se consideran sinónimos, por ello, en lo personal prefiero los títulos universitarios de la carrera que empiezan con “ingeniero de” sobre los que utilizan “ingeniero en” porque al sustituir ingeniero con constructor tiene mucho más sentido “constructor de” que “constructor en”. El punto es que un ingeniero es alguien práctico y no un acumulador de conocimientos o erudito “en” una determinada rama del saber.
Resumiendo las tres facetas, una definición de ingeniería sería:
Ingeniería es disponer de la ciencia para analizar un problema, diseñar la solución y trabajar para construirla.
Imagine Cup 2009, a Segunda Ronda
Escrito por Leonel en Diseño, Imagine Cup, Ingeniería el Abril 22nd, 2009
El pasado lunes recibí el tan ansiado aviso de Imagine Cup donde me indican que había calificado para pasar a la segunda ronda.
En la carta también venía un enlace a la página donde se pueden consultar los resultados de todas las categorías menos la de Software Design, que se define hasta hoy miércoles 22.
Carta de Imagine Cup donde me indican que avanzo a la siguiente ronda
| País | Participantes | Avanzaron |
|---|---|---|
| Guatemala | 10 | 2 |
| El Salvador | 7 | 2 |
| Honduras | 6 | 2 |
| Nicaragua | 0 | 0 |
| Costa Rica | 5 | 1 |
| Panamá | 4 | 1 |
| Belice | 0 | 0 |
| México | 62 | 27 |
| USA | 248 | 76 |
| India | 428 | 108 |
| Japón | 610 | 79 |
Hay otros países con participación importante pero que no incluí en este resumen.
De momento entonces tenemos dos participantes de Guatemala en segunda ronda, uno en la competencia de Photography, de la UFM, y su servidor en Design, representando a la Galileo. La gente del El Salvador clasificó en Design for Development, y en Design. Los hondureños se metieron en una competencia de alto nivel: Robotics & Algorithm, y el tico en otra no menos complicada: IT Challenge. Claro, no estoy diciendo que Design y Photography no tengan un alto grado de dificultad, al contrario, eso lo demuestra el hecho de que en Design participaron 335 equipos y solo pasaron 150, en Photography 1249, de los cuales clasificaron 224.
En el transcurso de la semana conoceremos los resultados de Software Design, donde se que también hay chapines participando.
La parte importante de la carta, ¡Avancé!
Jef Raskin y las Leyes del Diseño de Interfaces
Escrito por Leonel en Diseño, Ingeniería, Interfaz de Usuario, Programación, Usabilidad el Abril 8th, 2009
El libro de Jef Raskin se llama en español Diseño de Sistemas Interactivos: la Importancia de Nuestra Relación con las Computadoras
La semana pasada terminé de leer “Diseño de Sistemas Interactivos” del difunto Jef Raskin (1943 – 2005). Este libro es una traducción de “The Humane Interface: New Directions for Designing Interactive Systems”, y confieso que nuevamente me sucedió lo mismo que con el libro “Presos de la Tecnología” (traducción de “The Inmates are Running the Asylum” de Alan Cooper), es decir, me enteré de las excelentes referencias del escrito hasta que revisé su nombre en inglés. Es asombroso lo mucho que puede cambiar el nombre de un libro cuando lo traducen al español.
Curiosamente ambos libros los compré en rebaja por menos de Q30.00 en la librería del IGA. Tengo que ir más seguido a comprar allí.
Volviendo al libro, me llamó la atención la analogía que Raskin hace entre las leyes de la robótica, postuladas por Isaac Asimov, y las que él considera que deberían ser las leyes del diseño de interfaces:
Primera: Una computadora no debe causar daño al trabajo del usuario, o, por su inacción, permitir que el trabajo del usuario reciba algún daño.
Segunda: Una computadora no debe hacer al usuario perder tiempo u obligarlo a trabajar más de lo que es estrictamente necesario.
Y no hay tercera, al parecer no hace falta más, con solo estas dos podríamos encontrar miles de ejemplos de interfaces fuera de la ley.
El libro también da muchísimos principios de diseño, algunos muy generales, como “los usuarios establecen el ritmo de una interacción”, y otros muy prácticos como “si un control debe operarse siempre, (o nunca) no lo proporcione”.
Esta es la portada de la versión en inglés que dice algo totalmente diferente a lo que dice en español, el contenido del libro se mantiene, la portada ¡nada que ver!
Siempre a la caza de nuevos retos de investigación y siguiendo en la línea de mi proyecto científico para el 2009, encontrar la descripción de ZoomWorld que Raskin hace en el capítulo 6, me hizo proponerme hacer una estructuración en metodología DEIU de ese interfaz de usuario.
Indagando un poco más encontré que ZoomWorld es solo una parte del proyecto Archy, también iniciado por Raskin, que a su vez es un ejemplo entre varias interfaces basadas en el paradigma de ampliación o Zooming Interface Paradigm – ZIP.
El primer esfuerzo por construir un ZIP fue el realizado por Ken Perlin, Jim Hollan y Ben Bederson y se llama Pad++, además es el que está mejor documentado y el que se ha mantenido activo por más tiempo.
El mejor conocido, sin duda, es Google Maps y Google Earth, aunque se puede argumentar que no se trata estrictamente de un ZIP sino de una aplicación de técnicas de ZIP para un interfaz de aplicación. Eso es discutible.
De vuelta de nuevo al libro, Raskin presenta un interesante discusión sobre lo que él dice debería ser un Interfaz Humano, como un paso adelante a lo que se podría llamar simplemente interfaz humano-computador. “Una interfaz es humana si responde a las necesidades humanas y es considerada con las limitaciones humanas” en contraposición las interfaces han sido diseñadas tradicionalmente con el enfoque de atender primero las necesidades de las máquinas o los requerimientos de información de los sistemas o el modelo mental del programador. Hay que mejorar la enseñanza de los factores humanos y su aplicación en el diseño en las escuelas de ingeniería de software.
En el libro se tocan otros temas interesantes también, como el de la cognética – la ergonomía de las facultades cognoscitivas – o el de la definición de interfaz de usuario que me interesa particularmente y sobre el que espero escribir en otro artículo.
En resumen, se trata de un libro muy bueno, un auténtico clásico de la literatura de HCI y de usabilidad de sistemas interactivos. Me encantó especialmente un párrafo casi al final del libro, en el capítulo siete, donde se tocan temas diversos, hablando sobre las sofisticadas interfaces de los ambientes de programación modernos y su diferencia con las sencillas herramientas de programación antiguas:
Algo francamente maravilloso se ha perdido: en particular la retroalimentación inmediata que necesitan los humanos a fin de iterar con rapidez su camino hacia un programa efectivo. No soy tan ingenuo para pensar que podemos mantener la sencillez original por completo y alcanzar el nivel de complejidad de los programas que ahora se demanda, pero estoy seguro de que podemos hacerlo mucho mejor que lo que tenemos.
Mi diseño para Imagine Cup 2009
Escrito por Leonel en Diseño, Imagine Cup, Interfaz de Usuario, Internet el Abril 3rd, 2009
Primera diapositiva de la presentación que envié a Imagine Cup 2009
Pero cuando empecé a ver cómo hacía para terminar la maestría que había empezado en 1995 en la Galileo, me di cuenta que tenía oportunidad de hacerlo.
Me matriculé en la U en el 2007 y cursé el último curso que necesitaba en el primer trimestre de 2008 y con eso ya estaba habilitado para participar en el 2009. Pude haber participado en la edición del 2008 pero perdí esa oportunidad.
El tema para Imagine Cup 2009 es “imagine a world where technology helps solve the toughest problems facing us today” y básicamente de lo que se trata es de entrarle a los problemas que se deben resolver para alcanzar las metas del milenio, o sea, reducir el hambre y la pobreza, proveer educación primaria universal, promover la equidad de género, reducir la mortalidad infantil, etc., es decir, problemas bien complicados.
Pero eso es parte del atractivo de Imagine Cup, que no solo dejan que uno se imagine cualquier idea, sino que tiene que ser algo que pueda tener resultados bien concretos.
Hay varias categorías de competencia, la más difícil es Software Design, que es en la que no solo hay que diseñar el software sino que construirlo y hacer que funcione.
A mi me había llamado más la atención la categoría de Interface Design, por ser algo a lo que desde hace rato le había dedicado bastante atención. Es una competencia menos reñida, y con menos premios, pero igual muy interesante.
El asunto es que el año pasado después de anunciar la convocatoria resultó que habían eliminado esa categoría, lo cual fue una sorpresa no muy agradable para mí.
Ya me había resignado a que de plano no participaba cuando apareció una nueva categoría: “Design” o sea, diseño, sólo diseño. Viendo las descripciones y reglas vi que podía ser adecuada para participar porque al final casi era lo mismo que la desaparecida Interface Design.
Había que pensar una idea, luego preparar una presentación en Power Point y enviarla.
Pasé varios días de Diciembre y Enero aprovechando mis caminatas al trabajo para pensar y concretar algo que pudiera tener alguna posibilidad de presentar para competir. De alguna forma me había planteado varios requerimientos o restricciones para el diseño a formular: tenía que involucrar a la radio, porque es el medio de más penetración en las áreas alejadas, y también al celular, por lo fácil que es llevarlo a esos lugares.
La idea tiene que ver con unir a las personas que están en línea con las que están menos que en línea
Finalmente se me ocurrió una idea que consideré que valía la pena, armé la presentación que quedó de 36 dispositivas, la descripción en menos de 100 palabras y la metí a la competencia.
Después me enteré que hay participantes que mandaron presentaciones de 60 diapositivas… ¡Ups! Espero no haber sido demasiado escueto. También hay otros que vienen con la experiencia de 4 competencias anteriores en las que han llegado a las finales. No será entonces tan fácil como habría podido esperar.
La competencia es en tres rondas, la primera se acaba de cerrar el pasado 1 de abril, los resultados los dan el 20 de este mes y empieza la ronda 2 entre los que hayan calificado. La ronda final, o sea las finales, son en Egipto y solo llegan los que hayan calificado de la segunda ronda y en principio serán sólo 6.
En lo personal me siento un poco mayorzón para andar en estos rollos. Si ven las fotos de la competencia se podrán dar cuenta de que los participantes son bien patojos, y yo ya estoy por entrar a los 40, debería pensar más bien en ser tutor de participantes, pero dado que los requisitos están cumplidos le hago ganas.
A ver qué tal.
El ciclo de ingeniería
Escrito por Leonel en Diseño, Ingeniería, Usabilidad el Marzo 22nd, 2009
Las cuatro actividades principales del ciclo de ingeniería: analizar, diseñar, construir, evaluar.
En este artículo, “Usability Engineering Turns 10”, publicado en la revista especializada Interactions de la ACM, Butler explica en qué consiste la ingeniería de la usabilidad y por qué puede considerarse una rama de la ingeniería con todo derecho.
Su argumento básico es que sigue el ciclo de ingeniería. Hasta ese momento la usabilidad era para mi algo así como la aplicación de la teoría conocida sobre factores humanos, computadoras y usuarios para construir sistemas que fueran fáciles de usar y de entender, eficientes y satisfactorios. Pero no la entendía como una ingeniería.
Tampoco estoy seguro de que yo entendiera bien cuál es la esencia de la ingeniería, y eso a pesar de que para ese entonces llevaba ya más de 3 años de haberme graduado y más de 10 de haber cerrado ingeniería y estaba estudiando la maestría.
El ciclo de ingeniería consiste en una serie de actividades que se realizan iterativamente en cada proyecto. En mayor o menor medida el ingeniero las planifica y ejecuta una o varias veces si es necesario, de acuerdo a la naturaleza del proyecto.
Para algunos proyectos de ingeniería el ciclo se ejecuta una sola vez, pero en otros, especialmente en los de ingeniería de sistemas, el ciclo puede recorrerse varias veces hasta alcanzar la solución. Se construyen múltiples prototipos que pueden desecharse hasta llegar a la versión final.
En el diseño se plantea la solución a implementar. A pesar de que la solución puede ser de común aplicación en la industria o para el tipo de problema que se intenta resolver, la adaptación que se requiere para las circunstancias concretas puede implicar una innovación considerable. Si la solución es novedosa entonces resulta innovadora por sí misma. Así que todo diseño de ingeniería siempre implica innovación.
Luego inicia la construcción. Tanto el diseño como la construcción son etapas bien específicas para cada rama de la ingeniería, no se ejecutan igual si se trata de un proyecto de ingeniería química o de ingeniería mecánica y definitivamente no con las mismas perspectivas. Se puede decir que la construcción es la parte administrativa de un proyecto de ingeniería, ya que implica planeación, organización, dirección y control, que son las cuatro funciones administrativas comúnmente aceptadas. Dependiendo del proyecto la construcción puede resultar la etapa más larga.
En la evaluación se hace un examen de cómo se llevó a cabo el proyecto, si se resolvió el problema que se había planteado y si se hizo de una forma efectiva y eficiente. Puesto que no es conveniente dejar esta etapa exclusivamente para el final, ya que ayuda a identificar errores y efectos negativos que es importante resolver tan pronto como sea posible, es común que las evaluaciones se hagan con cada etapa parcial del proceso de construcción.
El ciclo se cierra cuando del resultado de la evaluación se desprenden nuevos problemas que requieren nuevamente de análisis, diseño, construcción y evaluación.
Algunos autores definen un ciclo de ingeniería con más actividades principales de las que se plantearon aquí. A mi me parece que estas cuatro especifican muy bien lo esencial de cualquier ciclo de ingeniería y que de hecho identifican lo que podríamos llamar el método de ingeniería, pero eso será tema de otro artículo.
Encabezado del artículo de Butler, publicado en 1996 en la revista Interactions de la ACM.
El diseño en ingeniería
Escrito por Leonel en Diseño, Ingeniería el Marzo 9th, 2009
Feria de Ingeniería en la Universidad Rafael Landívar en Guatemala
Un diseño es la expresión de una idea que soluciona de forma innovadora un problema concreto y sirve de guía para llevarlo a la práctica, es decir, para construirlo y evaluarlo.
De todas las ramas de la ingeniería, los planos de construcción en las obras civiles son la expresión más popular de diseño. Con el tiempo han alcanzado un buen nivel de accesibilidad y muchísimas personas sin formación técnica pueden entenderlos sin mayor explicación.
No ocurre lo mismo en el resto de ramas de la ingeniería. En mayor o menor grado es posible pasar directamente del análisis a la construcción sin tener un diseño bien especificado.
Probablemente se deba a que el ingeniero es una persona práctica que se apasiona por solucionar un problema en cuanto termina de planteársele. Esta pasión, sin embargo, puede jugar en contra de la eficiencia en el proceso e incluso poner en riesgo todo el proyecto.
El caso más crítico es el de la ingeniería de sistemas informáticos, donde a menudo de hecho apenas se cubre algo del análisis y se pasa directamente a la codificación, que aquí equivale a la construcción.
Un profesor universitario lo resumía de esta forma “their design was the code” o “su diseño era el código”, como tratando de decir que simplemente habían empezado a codificar sin ningún diseño.
Las desventajas de trabajar sin diseño son muchas: falta de una orientación adecuada para el equipo, ya que cada miembro puede tener ideas diferentes sobre lo que se quiere construir; se puede adelantar mucho en la construcción y tener que desecharlo todo por falta de consistencia o porque simplemente se asumió algo que después resulta incorrecto; se le dedica demasiado tiempo a aspectos del problema y se descuida otros de igual o mayor importancia; no hay forma de evaluar si lo que se ha avanzado corresponde en tiempo y esfuerzo a lo que se habría esperado; y un largo etcétera.
Una vez más, hay fallos en la formación universitaria del ingeniero que promueven este vicio. Para empezar muchos profesores alientan a los alumnos a iniciar el trabajo sin exigir que primero se tenga un diseño. Simplemente asumen que no es necesario, que ya habrá otro curso en donde se les enseñe eso o que para el caso particular no aplica.
Los diseños pueden tomar muchas formas: prototipos, maquetas, esbozos en papel, diagramas, dibujos, storyboards (secuencias de dibujos que muestran cómo funcionará el artefacto terminado). En ingeniería de sistemas son muy populares los diagramas UML pero aunque son una excelente herramienta de ninguna forma se pueden considerar suficientes, sobre todo para sistemas interactivos que involucran usuarios. En estos es muy necesario acudir a los bosquejos, prototipos en papel, y otras formas de modelado, para dar oportunidad al usuario final de revisar si lo que espera del sistema es en realidad lo que se está construyendo.
Diseñar implica tomar decisiones. Se escoge una opción y se elimina el resto de posibilidades, para definir el diseño concreto. Estas decisiones implican criterio, compromiso y responsabilidad. Criterio porque no se pueden tomar simplemente por gusto o por conveniencia propia. Compromiso porque la decisión tomada debe acompañar todo el ciclo de ingeniería hasta la evaluación final, estando preparado para recibir cuestionamientos si hace falta. Responsabilidad porque las decisiones tomadas afectarán no solo a la obra construida sino a todos los involucrados, incluyendo a los usuarios finales.
En una conferencia del Dr. Fernando Cajas le escuché decir que más que matemáticas y física – materias tradicionalísimas en las escuelas de ingeniería – lo que había que enseñar era cómo diseñar.
Diseñar en ingeniería es idear un artefacto que resuelve un problema concreto – en oposición a un problema general, que estaría más relacionado con investigación. Enfocarse demasiado en las habilidades numéricas y los problemas abstractos que presentan las matemáticas y la física solo confina a los estudiantes a un ámbito muy restringido del universo de situaciones que enfrentan los ingenieros como profesionales. Lo peor que podría pasar es que ellos creyeran que de eso se trata la ingeniería.
Por supuesto que tiene muchísimo que ver con matemáticas y física, pero definitivamente va mucho más allá.
Comentarios recientes