history

warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

Mecanismos emergentes de desregulación en la red

Submitted by gwolf on Thu, 11/22/2012 - 12:09
Written in...: 
2012

Throughout the years, since the Internet was opened for commercial use in the mid-1990s (and gave way for the bulk of the population to start using the network, leading to the massification towards the end of the decade) the notion that the cyberspace is a bold new free space, without rules or regulations, ruled for some time. In those years it was common to refer to the Internet as to a «Wild West» where anybody could do whatever they pleased.

Little by little, that apparent lack of laws started to change, be it as laws usually applied to other scopes started being applied, be it because of specific laws regarding online behaviour. We also started seeing the legal difficulties this meant: An almost constant extraterritoriality of each of the parties (and computers) involved in every action.

However, going back to the origins of the Internet as a research network founded by the United States Department of Defense, how this space, by nature highly regulated, became the ideal place for freedom of expression and anonymacy to flourish becomes a natural question.

Today, Internet is migrating towards a model strongly linked to the two large "social networks": Twitter and Facebook. This migration poses important changes in the way we relate to computers — to such a degree it has to be more deeply analyzed. In the third part of this exposition I sketch the main challenges this means to us.

This presentation was prepared for the Agencia Latinoamericana de Información (ALAI) seminar in Quito, Ecuador, 2012-11-22.

Resumen: 

A lo largo de los años desde que Internet se abrió para uso comercial a mediados de los 1990 (y por tanto se dio entrada a la población en general, masificándose hacia fines de dicha década) ha privado la visión de que el /ciberespacio/ es un ámbito nuevo, libre, carente de regulaciones y leyes. Hacia esos años era común referirse a Internet como un nuevo «Salvaje Oeste» en el que cualquiera podía hacer lo que quisiera.

Poco a poco, esa aparente falta de leyes fue cambiando, sea por la extensión de leyes aplicables a otros ámbitos de la vida, sea por leyes específicas a las conductas en línea. Fueron apareciendo también las dificultades legales que suponía este entorno: Una casi constante extraterritorialidad de cada uno de los equipos y personas involucradas en cualquier acción.

Sin embargo, partiendo los orígenes de Internet como una red de investigación del Departamento de Defensa de los Estados Unidos de América, se hace natural la pregunta de cómo es que un espacio altamente regulado por naturaleza se volvió el entorno ideal de la libertad de expresión y el anonimato.

Al día de hoy, Internet está migrando hacia un modelo fuertemente basado en las dos grandes "redes sociales": Twitter y Facebook. Esta migración nos plantea importantes cambios en la forma de relacionarnos con las computadoras — A un grado tal que merece un análisis más profundo. En la tercer parte de esta exposición delíneo los principales retos que esto nos significa.

Esta presentación fue preparada para el seminario de la Agencia Latinoamericana de Información (ALAI) en Quito, Ecuador, 2012-11-22.

Los juegos: Clave para el desarrollo del cómputo

Submitted by gwolf on Sat, 04/14/2012 - 18:33
Wolf G.  2012.  Los juegos: Clave para el desarrollo del cómputo. Software Gurú. :50-51.

En el principio era el tiro parabólico

El desarrollo de juegos está relacionado con el desarrollo del cómputo prácticamente desde sus inicios. A pesar de que durante décadas las computadoras estaban al alcance únicamente de algunas grandes (y muy serias) instituciones militares y académicas, ya desde la década de 1940 hubo acercamientos lúdicos a diversos temas con fines de investigación: En 1947, Thomas T. Goldsmith Jr. y Estle Ray Mann diseñaron un primitivo sistema (controlado por una computadora de únicamente ocho bulbos) que mostraba en una pantalla tipo televisión la trayectoria descrita por misiles, cuyos parámetros dependían de la posición de varias perillas. Este "juego" no implementaba lógica alguna de detección de colisiones: El usuario colocaba una plantilla con su objetivo sobre la pantalla. Y podríamos imaginar las hipotéticas discusiones de los niños acerca de si dió en el blanco o se pasó apenitas (hipotéticas, claro, porque el sistema, si bien fue patentado con tal fin, nunca llegó al mercado).

Este primer juego era prácticamente un desarrollo natural, si tomamos en cuenta que las primeras computadoras electrónicas funcionales fueron creadas durante la segunda guerra mundial precisamente para hacer cálculos de trayectorias balísticas. Pero no deja de llamar la atención que uno de los juegos que más se asocia con el éxito de las aplicaciones en plataformas móviles, Angry Birds de la compañía finlandesa Rovio Mobile (comercializado en 2009 — ¡60 años más tarde!) sigue siendo básicamente un juego de tiro parabólico, aderezado con elementos gráficos y humorísticos, y con un sinfin de nuevos niveles y actualizaciones.

¡Y en Cambridge se juega así!

Pocos años más tarde, en 1952, Alexander S. Douglas escribió una versión gráfica del juego del gato (muy atinadamente llamada OXO) como proyecto para su tesis doctoral de interacción hombre-máquina en la Universidad de Cambridge, en una época en que no existían aún los dispositivos de entrada y salida (teclados y pantallas) que hoy damos tan por sentado, modo de interacción que apenas comienza a sentir presión de cambio tras cerca de 50 años.

Para 1959 aparecieron los primeros juegos gráficos en el MIT: Otra implementación del gato y el ratón en el laberinto. Estos juegos eran controlados por una pluma lumínica, con una forma de interacción, aunque salvando las distancias que más de 40 años ponen en el medio, muy similar a la táctil, que se ha puesto de moda en dispositivos móviles.

Jaque al rey: Persiguiendo la inteligencia artificial

Otro de los grandes hitos del desarrollo del cómputo que fueron marcados a través de los juegos es una gran subrama de la inteligencia artificial que llevó al diseño de incontables algoritmos de exploración de árboles de decisión con demasiados estados posibles para una búsqueda exhaustiva: A diferencia del gato, donde hay un máximo de 26,830 juegos posibles, la explosión combinatoria de posibilidades en el ajedrez, y la importancia de seguir una estrategia con un horizonte a varios movimientos. Si bien ya ha quedado demostrado que jugar ajedrez no demuestra inteligencia, buscar cómo enfrentarse a un oponente humano con cierto grado de éxito sí marcó grandes hitos en el desarrollo de esta importante disciplina.

En 1950, Claude Shannon publicó el artículo "Programming a Computer for Playing Chess" en la revista "Philosophical magazine". En 1951, Dietrich Prinz presentó un programa capaz de encontrar si era posible llegar a un mate en dos jugadas (un gran logro, dados los límites de la memoria a esas alturas). Para 1958, Alex Bernstein programó un jugador de ajedrez capaz de llevar a cabo un partido completo, aunque bastante fácil de vencer.

Y desde ahí, continuó el perfeccionamiento de los jugadores automatizados de ajedrez, hasta que en 1997 IBM alcanzó el hito de derrotar al campeón mundial en esa época, Gary Kasparov, con su computadora Deep Blue. Y cabe mencionar que, si bien el motor que animó a la exploración y desarrollo de técnicas
automatizadas para jugar ajedrez como parte del avance de la inteligencia artificial, esto no significa que Deep Blue sea más inteligente que Kasparov o, de hecho, que sea calificable de inteligente: El hito que se logró es optimizar un algoritmo de búsqueda específico a un problema dentro de un campo con un espacio de posibilidades que puede considerarse efectivamente infinito.

Si les interesa leer específicamente acerca del desarrollo del ajedrez como disciplina computacional, les sugiero visitar http://chessprogramming.wikispaces.com/.

Para cerrar este apartado: Otra razón que da especial importancia al ajedrez dentro del listado que estoy presentando es que, de entre los juegos primigenios, éste es el primero en el que la computadora asume un rol activo: No se limita a presentar el tablero, llevar el estado del juego o asegurarse de que los jugadores efectúen movidas legales, sino que es el primer intento que se hace de sobrepasar competitivamente al humano, colocándolo en el lugar del contrincante.

Gráficas, redes... ¡A matar marcianitos!

En la década de 1960, las computadoras proliferaron en las universidades, y cada vez más, ya no eran sólo los profesores quienes podían utilizarlas, sino que los alumnos comenzaron a tener acceso y, obviamente, llegó un gran influjo de nuevas ideas. Para 1961, los alumnos del MIT Martin Graetz, Steve Russell y Wayne Witanen crearon el primer juego con uno de los temas más recurrentes de esta categoría: La guerra en el espacio, precisamente con el juego «Spacewar!» — Y en este caso, a diferencia de los mencionados anteriormente, lo hicieron puramente por diversión, para aprender a programar la unidad gráfica vectorial de la computadora DEC PDP-1 recién adquirida por su universidad.

Spacewar! era un juego hecho para dos jugadores que se enfrentaban en un duelo espacial, con interacción en tiempo real, aunque necesariamente frente a la misma consola. Este juego llegó a ser tan popular que se convirtió en uno de los programas empleados como demostración por el personal de DEC.

Paralelamente, eran cada vez más comunes los sistemas de tiempo compartido, donde varios usuarios podían sentarse cada uno frente a su propia terminal y usar la misma computadora. Estas computadoras además ofrecían normalmente la capacidad de comunicarse entre sesiones. No tardaron en aparecer los primeros juegos multijugador, en los que cada uno de los participantes asumía un rol distinto. En 1971 fueron desarrollados juegos como Star Trek o Baseball, en que los participantes tenían que actuar como equpios.

Los primeros juegos de acción multijugador con perspectiva 3D en primera persona (First-person Shooters) llegaron en 1974: Spasim (Space Simulator), en los sistemas PLATO de la Universidad de Illinois, y Maze War, en el centro AMES de Investigación de NASA en California.

Y hacia mediados de los 1970, ya con Internet floreciendo entre las principales universidades de Estados Unidos, comenzaron a aparecer varios MUDs, mundos en línea de aventuras interactivas, verdaderamente multijugador, presentando prácticamente todos los elementos que esperaríamos hoy de los juegos en plataformas de interacción social — Cierto, acorde a la tecnología disponible, pero con niveles de interacción social muy cercanos a los que conocemos hoy.

El BBS: Las redes para el resto de nosotros

Ya en los 1980, tras la explosión de la revolución de las computadoras personales, pero mucho antes de la masificación del acceso a Internet, grupos de aficionados de todo el mundo comenzaron a conectarse entre sí con los medios que la tecnología ofrecía: Comenzaron a aparecer Sistemas de Boletín Electrónico (Bulletin Board Systems o BBSes), computadoras personales de entusiastas conectadas a una línea telefónica, programadas para recibir llamadas de quien quisiera pasar un rato por ahí, para platicar en los foros, intercambiar archivos — O participar de los juegos multijugador, aunque en este caso, dado que las conexiones eran telefónicas, casi todos eran con una interacción basada en turnos.

No puedo dejar de mencionar a los BBSes dado que, hacia principios de los 1990, fui operador de uno de los aproximadamente 20 BBSes que hubo en la Ciudad de México por aquellos días. Llegamos a tener comunidades vibrantes, de aproximadamente mil usuarios, que poco a poco fuimos migrando a Internet. Algunos de los juegos BBSeros, como el TradeWars 2002, reaparecieron años más tarde en Internet, aunque manteniendo en su formato original basado en texto en una terminal de 80×25 caracteres.

Como en tantos otros casos, en el campo de los juegos por computadora el verdadero desarrollo e inovación se dio cuando no había aún referentes, en las primeras décadas. Y aunque el mundo de los juegos parece compeltamente distinto hoy de lo que era hace 5, 10 o 20 años, la principal diferencia es el uso de gráficos y sonido, o la capacidad de almacenamiento (y por tanto, de interacción) a disposición del usuario, no las ideas principales.

Hemos, a últimos años, visto muy interesantes cambios en la forma de interacción, con los controles basados en acelerómetros (Nintendo Wii) o en reconocimiento de imágenes (Kinect). Queda mucho por explorar, por inventar. Y dado cómo han ido de la mano el avance del cómputo y de los juegos, espero que los lectores de esta revista inyecten nueva vida y nuevas ideas en este campo. Estas ideas indudablemente terminarán alcanzando a nuestra disciplina completa.

( categories: )

Los muchos significados del «cómputo en la nube»: Desmitificando el concepto

Submitted by gwolf on Fri, 01/14/2011 - 11:15
Wolf G.  2010.  Los muchos significados del «cómputo en la nube»: Desmitificando el concepto. Software Gurú. :48-49.

Uno de los términos ampliamente en boga en nuestro campo hoy en día es el cómputo en la nube. Tan en boga que me parece que se ha convertido en una palabra mágica, bastante hueca y sintomática de querer parecer en sintonía con los últimos desarrollos tecnológicos, sin comprenderlos en realidad. Además, al ser una frase que de golpe comenzó a escucharse con tanta insistencia, asumimos que es una estrategia nueva, una idea posibilitada por los nuevos avances tecnológicos — Y esto dista de ser el caso. En esta columna busco clarificar los conceptos y tipos básicos de cómputo en la nube, sus principales ventjas y desventajas, y brevemente encontrar paralelos con casos documentados de estos ”novedosos” conceptos

No critico, ojo, a las estrategias que están detrás de este sonoro término — Muy por el contrario, resultan muy convenientes a la hora de implementar, y como profesionales del desarrollo de software tenemos la obligación de estar familiarizados con ellas. Lo que critico es el abuso de un término ambíguo, que suele poner en problemas a los implementadores, al no estar claramente comprendido.

La mayor parte de las referencias que consulté mencionan a tres capas o niveles principales: El software –o la aplicación– como un servicio (Software as a Service, SaaS), la plataforma como un servicio (Platform as a Service, PaaS) y la infraestructura o el hardware como un servicio (Infrastructure as a Service, IaaS). Mi punto de vista, es que más que un nivel distinto, IaaS es un conjunto de cualidades adicionales que dan valor agregado a una oferta de PaaS.

SaaS: Bloques de construcción

Cuando uno de nuestros sistemas utiliza un API público remoto, o cuando para nuestro flujo de trabajo empleamos a una aplicación que reside y es administrada fuera de nuestra organización, estamos empleando SaaS. Nuestro proveedor puede cobrar su servicio de diversas maneras: A través de una renta directa, requiriendo del despliegue de publicidad, recibiendo autorización para recolectar nuestra información y hacer minería de datos sobre de ella — Hay una enorme variedad de esquemas, que refleja la gran variedad de niveles de integración que se puede dar a los servicios.

Notarán que la principal diferencia con los esquemas tradicionales cliente-servidor con que hemos trabajado desde hace décadas es el uso explícito de un proveedor externo — Sin embargo, técnicamente, nuestros sistemas no seguirán una lógica o un proceso de desarrollo diferente de como lo vienen haciendo por décadas.

Al mismo tiempo, sí hay una importante diferencia: Al no controlar nosotros el proceso que ocurre dentro de uno de nuestros subsistemas, nos vemos forzados a hacer bien lo que ya deberíamos estar haciendo: Implementar una separación limpia de responsabilidades entre los componentes, utiilzar exclusivamente las interfaces publicadas explícitamente — No brincarnos las capas de abstracción, como muchas veces estaríamos tentados a hacerlo en un proyecto meramente interno.

Hay un punto que no podemos perder de vista cuando empleamos un servicio de aplicaciones como parte de nuestra infraestructura en sistemas: Al depender de un tercero, ponemos en sus manos parte importante de nuestras promesas (y, por tanto, requerimientos), en tanto a disponibilidad, protección de datos y continuidad de la operación. Tocando el primer punto, resulta natural: Una falla en el servicio de cualquiera de nuestros proveedores de aplicaciones llevará a que nuestro sistema presente información incompleta o errónea a sus usuarios.

Respecto al segundo, no sólo debemos tener en cuenta las implicaciones directas (el proveedor tendrá acceso a todos los datos específicos que le enviemos para operar), sino que las indirectas: Todo ataque por medio del cual un agente hostil pueda llevar a cabo recolección de información sobre de nuestros proveedores resultará en la probable divulgación de información interna nuestra, e incluso el mismo proveedor puede estar realizando un seguimiento estadístico de nuestros patrones de uso, revelando mucho más de lo que podríamos querer darle.

En tanto a la continuidad de operación, si el proveedor del servicio decide cambiar los términos bajo los cuales brinda sus recursos, o si sencillamente deja de operar, podemos quedar sin una alternativa disponible para parte importante de nuestro flujo de trabajo.

Como corolario de la dependencia de terceros, al depender de aplicaciones como servicio perdemos la capacidad de planear las actualizaciones de nuestra infraestructura — Al depender de proveedores externos, en el momento en que cualquiera de sus APIs cambia, nos vemos forzados a actualizar de inmediato. Nuestros servicios en producción pueden fallar, y el mero concepto de rama estable pierde buena parte de su atractivo1.

PaaS+IaaS: Flexibilidad en el uso de recursos

Mientras que en el apartado anterior partíamos de que –desde el punto de vista del usuario– hay una aplicación central que corre en sus instalaciones y consume procesamiento realizado por componentes distribuídos por el mundo (”en la nube”), aquí la aplicación completa será desplegada en el proveedor de servicios. El usuario deja de emplear un servidor –o una granja de servidores– para consumir sólo los recursos. Y, consecuentemente, el esquema de utilidad para un proveedor de servicios bajo esta modalidad puede ir desde la renta a costo fijo hasta un cobro por uso de recursos, típicamente permitiendo reconfiguraciones dinámicas del paquete (del conjunto máximo de recursos) como respuesta a la demanda del sistema.

La justificación detrás de este concepto es que los servidores ”en casa” representan un gasto demasiado grande — Compra y actualización periódica de equipo, consumo eléctrico, uso de espacio físico y de ancho de banda, siendo que las instalaciones de la mayor parte de los usuarios no cuentan siquiera con un centro de datos. Además, todo servidor debe ser adquirido contemplando la carga estimada que sostendrá, pero contemplando un espacio para sobreconsumo en picos de actividad no planificable. En cambio, un proveedor masivo de servicios balancea el exceso de demanda de un usuario con la reducción de demanda de otro, permitiendo un menor sobredimensionamiento — Y una reducción neta de precios.

Nuevamente, apreciarán que la idea no es nueva — Los proveedores de presencia o de hosting existen desde hace muchos años en Internet. Más allá aún, precisamente este esquema fue planteado a mediados de los 1960, cuando fue desarrollado el sistema MULTICS2.

La principal diferencia con el esquema tradicional de renta de servidores es que bajo este esquema, el usuario deja de ser responsable de la administración incluso del servidor en el que se ejecutarán sus aplicaciones; el proveedor de servicios ofrece una cartera de plataformas administradas. Las plataformas pueden ser desde aplicaciones medianamente complejas, como plataformas Web que llevan un grado no trivial de configuración y representan una solución completa e integrada, hasta marcos para el desarrollo de sistemas (como Rails, Struts, Django, GWT), para los cuales los clientes sólo proveen el código específico de su aplicación, y aprovechan todo el andamiaje común que ya existe para una amplia base de clientes.

Respecto a consideraciones de seguridad y confiabilidad: Si bien al emplear PaaS no caemos ya en la trampa descrita en el primer apartado respecto a emplear código del cual no tenemos más conocimiento que el API, éste esquema sigue depositando todos nuestros datos en control del proveedor, en infraestructura compartida, con lo cual la probabilidad de que un ataque a un sistema sin relación aparente con el nuestro puede dar a un intruso acceso pleno a nuestra información.

El riesgo de que el proveedor cambie sus políticas de cobro a un esquema que no nos convenga se reduce también fuertemente, dado que en principio tenemos todo lo necesario para replicar la instalación con cualquier otro proveedor, o incluso migrar a una solución ”en casa”. Sin embargo, seguiremos sujetos a los días bandera de actualización forzada, dado que el proveedor típicamente ofrecerá la misma versión base a todos sus clientes — Y este factor puede dificultarnos una migración entre proveedores.

Hablando meramente de la conveniencia: Podemos enviar a uno de nuestros sistemas a la nube dados sus requisitos de almacenamiento de información, o de ancho de banda. Ahora bien, ¿cómo estamos realizando nuestros respaldos? Para poder hacer frente a contingencias, contar con una estrategia de respaldos buena y probada es mucho más importante aún que cuando hablamos de despliegues en infraestructura propia.

Por último, respecto al IaaS: Este resulta el más nebuloso y ambiguo — Ya no se trata de sistemas o entornos para que éstos se ejecuten, sino que de recursos de cómputo que están a nuestra disposición: Espacio en disco o en memoria, ”ticks” de procesador, ajuste de ancho de banda, como componentes discretos y ajustables en vivo — Atributos que se apoyan fuertemente en la virtualización para poder ser desplegados y controlados.

Hay quien incluye la virtualización de escritorios dentro de la definición de IaaS, pero si mucho, eso debe ser visto como consolidación de recursos y mejoría en el aprovechamiento de recursos, pero por calidad en el servicio debe hacerse utilizando recursos internos a la organización — Y por tanto, se aleja de las definiciones básicas de en la nube.

Llevamos años haciendo cómputo en la nube de un tipo o de otro. Al desmitificarlo un poco, espero abonar a una mejor utilización. Y al hablar acerca de los nada ignorables riesgos que conlleva, apunto a la cautela que debemos tener al adoptarlo, no entrar de lleno sólo porque es la moda.

  • 1. Podemos ver un buen ejemplo de esto cuando Twitter cambió su esquema de autenticación en agosto de este año, obligando a cientos de aplicaciones a impulsar la migración a nuevas versiones — http://blog.twitter.com/2010/08/twitter-applications-and-oauth.html
  • 2. El sistema operativo MULTICS partía del planteamiento de que el cómputo se convertiría en un servicio provisto centralmente, como la electricidad o el teléfono. http://www.multicians.org/
( categories: )

Historia y futuro de la interfaz hombre-máquina

Submitted by gwolf on Mon, 08/23/2010 - 00:12
Wolf G.  2010.  Historia y futuro de la interfaz hombre-máquina. Software Gurú. :46-47.

Historia y futuro de la interfaz hombre-máquina

Frecuentemente nos mostramos maravillados de cómo ha avanzado la manera en que interactuamos con la computadora en los últimos años, sin detenernos a pensar cuánta verdad hay –o no– detrás de esta afirmación. A fin de cuentas, hace apenas unos años el uso de las computadoras era verdaderamente limitado, y hoy en día están en todos lados, y parecería que cualquiera es capaz de manejarlas — Al menos, en sus funciones básicas.

Yo sostengo que esta es una afirmación falsa, basada en las apreciaciones de gente ajena a nuestro campo, y producto más de la popularización que de un verdadero cambio cualitativo. Claro está, al poner en duda lo universalmente aceptado, recae en mí sustentar mi afirmación.

Vamos, pues, con un breve recorrido de cómo evolucionó la interacción hasta el día de hoy.

Los inicios

Las primeras décadas del desarrollo de la computación como una disciplina aplicada de la ingeniería (tomando como punto de partida de forma un tanto arbitraria a la primer computadora electrónica en 1943, ENIAC) verdaderamente vieron un cambio radical en la manera en que los usuarios se aproximaban a la computadora — Esto resulta poco más que una obviedad, dado que antes de 1943 no existían las computadoras siquiera.

Las primeras computadoras no tenían nada que hoy reconoceríamos como interfaz — Tanto instrucciones como datos eran introducidos directamente a las ubicaciones de memoria al iniciar la ejecución a través de tarjetas perforadas, y eran leídos de los registros del procesador, mostrándolos directamente en un volcado binario, hacia tarjetas o cintas perforadas, que debían ser traducidas a algo legible empleando dispositivos mecánicos independientes.

Teletipos y terminales

El primer avance resultó en una dirección obvia, pero facilitó tremendamente tanto el uso como el aprovechamiento de los resultados: La interfaz textual. No hablo aún de una pantalla, sino de la adecuación del teletipo, híbrido de teclado e impresora, que comenzó su existencia como un reemplazo más ágil y confiable que el código Morse para la comunicación a larga distancia. El teletipo permitía ingresar programas mucho más complejos a memoria, lo cual llevó a que naciera y popularizara un concepto que nos parece muy ajeno a las interfaces de usuario: El de los archivos. Aparecieron los primeros editores (obviamente, mucho más espartanos de lo que conocemos hoy, y orientados a trabajo línea por línea), y como consecuencia directa, los programas pudieron comenzar a presentar una mucho mayor complejidad – llevando a la introducción de bibliotecas de código y a las diversas abstracciones y estrategias para manejar la complejidad.

La transición del teletipo a la pantalla no es tan simple como podría parecer. Dejando de lado la mera complejidad técnica (relativa al estado del arte de la época) de crear dispositivos independientes y de relativo bajo costo capaces de mantener comunicación con la computadora central, generando la imagen en pantalla del texto que iban recibiendo — lo cual implicaba que tuvieran una memoria interna, aunque mínima para estándares modernos1, las ventajas de tener terminales con cierto grado de inteligencia se hicieron obvias, y comenzaron a aparecer terminales con diferentes estándares2 capaces de reposicionar el cursor, o de desplegar texto con atributos (negritas, subrayado, colores), caracteres semi-gráficos, hasta verdaderas capacidades de formularios como las que manejaban las IBM 3270, que comenzaron a permitir desacoplar la lógica de un programa de su presentación tal como hoy lo vemos en los navegadores Web.

Las terminales además fueron centrales para la aparición de computadoras multitarea/multiusuario. Quienes gustamos de utilizar sistemas Unix utilizamos como una de nuestras herramientas más poderosas al emulador de terminal, o como le dice el resto del mundo, la ventana negra. Si bien las terminales como producto de hardware hace mucho tiempo que ya no existen para propósitos prácticos, la interfaz de línea de comandos programable permite un grado de expresividad tan rico que no ha podido ser reemplazado por ningún otro medio.

WIMP: Window, Icon, Menu, Pointer

En diciembre de 1968, en los laboratorios de Palo Alto de Xerox, Douglas Engelbart presentó la que al día de hoy se conoce como la madre de todas las demos: La introducción de la interfaz gráfica básica que seguimos utilizando hoy en día, manejada a través de un apuntador controlado por un mouse, presentando ventanas para la visualización de las diferentes aplicaciones en uso (o vistas de una misma aplicación), iconos representando atajos a las acciones de sistema disponibles, y con un menú como elemento estándar presentando las acciones relacionadas con cada aplicación activa. Y, claro, para la entrada y manipulación de datos dentro de cada aplicación, el dispositivo primario seguirá siendo el teclado.

La demostración de Engelbart incluía ejemplos de aplicaciones verdaderamente revolucionarias en esa época, como la videoconferencia, el correo electrónico, el hipertexto o un editor colaborativo de tiempo real.

Y aunque ha habido refinamientos sucesivos y grandes cambios en la parte estética de esta propuesta, para las computadoras de uso general seguimos utilizando este esquema de interacción — Con más de cuarenta años de antigüedad.

Interfaces de propósito acotado

Posiblemente el mayor cambio en las interfaces de usuario viene de que, cada vez con mayor fuerza, tenemos dispositivos con gran poder de proceso de cómputo sin un formato de computadora de propósito general. No veo como casualidad que hoy veamos con entusiasmo a las interfaces tan revolucionarias como las presentes en teléfonos celulares o consolas de videojuego — Estamos llegando al punto en que vamos encontrando formas muy convenientes de interactuar con computadoras de propósito acotado, aunque éstas no sean adecuadas para aquellas de propósito general. Ilustro esto con dos ejemplos:

Con la generación actual de consolas de videojuegos, Nintendo se anotó el mayor éxito al introducir su Wii: Una consola de relativamente bajas prestaciones y muy inferior a su competencia en las áreas en que típicamente competían, la capacidad gráfica. Sin embargo, su apuesta más fuerte fue hacia una interfaz novedosa: Los controles basados en acelerómetros, que permitieron modelar diferentes actividades como nunca antes se habían presentado en videojuegos.

Por otro lado, el iPod de Apple introdujo una interfaz largamente prometida, basada en una pantalla táctil de tamaño reducido, y orientada a equipos destinados al entretenimiento, a la consulta rápida de información, y especialmente popularizada a través del teléfono aparecido poco tiempo después. Sin embargo, si bien esta interfaz ha resultado natural para una gran cantidad de personas, resultaría indudablemente impráctica y antiergonómica para una computadora de propósito general.

Y claro, seguiremos viendo nuevas interfaces dedicadas a tareas específicas — Las más exitosas serán, sin duda, las más transparentes: Las que se integren de manera transparente a las tareas, mejorando nuestra vida sin requerir que reparemos siquiera en su existencia. Por ejemplo, ¿cuánta gente está consciente de la cantidad de cálculos que se realizan en un automóvil? ¿No es acaso uno de los mejores ejemplos de cómputo ubicuo que se ha insertado silenciosamente en nuestras vidas?

Otras ideas

Han habido, claro, otras muchas propuestas de interfaces para uso general. En general no han sido bien aceptadas, o han sido empleadas sólo en contextos muy específicos. Algunos ejemplos son:

Pantallas táctiles
Desde mediados de los 1980, Hewlett-Packard introdujo su línea de computadoras HP110, con una pantalla sensible al tacto. Esta interfaz prometía ser más ágil y natural que el mouse (que requiere un nivel de coordinación no trivial). Y si bien esta interfaz tuvo un moderado éxito en áreas como los kioscos (cajeros automáticos, puntos de toma de pedido en restaurantes de comida rápida, etc.), nunca fue del todo aceptada para un uso general por lo poco ergonómico que resulta tener que levantar la mano constantemente para apuntar a puntos de la pantalla.
Reconocimiento de voz
La ciencia ficción de los 1970 (piensen en HAL de 2001 o en la serie Star Trek) presentó a la voz como la principal forma de interacción hacia la computadora (y un combinación de voz y despliegue en pantallas para los resultados). Se han ensayado interfaces de reconocimiento de voz, pero han fallado una tras otra por la dificultad que presenta el lenguaje humano, la alta variabilidad de los elementos que permiten reconocer las palabras en diferentes idiomas e incluso con diferentes acentos. Además de esto, fuera de dar comandos puntuales, "dictar" un texto a la computadora no es una tarea tan simple como podría parecer: Al redactar un texto, el proceso normal que seguimos implica ir hacia atrás y hacia adelante, corrigiendo el texto, reemplazando y reformulando las frases. Una interfaz de dictado deberá saber discriminar el texto de las órdenes, lo cual requerirá un entrenamiento nada trivial al usuario.
Manipulación 3D
Presentar la información como objetos del mundo real, manipulables a través de guantes o gestos, aparece como muy atractivo. Podemos ver un ejemplo muy cuidadosamente desarrollado de una interfaz basada en estas ideas en la película Minority Report (Steven Spielberg, 2002). El poder de procesamiento y el hardware especializado para hacer este tipo de manipulaciones, sin embargo, no justifica –al día de hoy– el costo que significaría. Hay aplicaciones, claro, para las que este costo sí se justifica; en México, la Dirección General de Servicios de Cómputo Académico de la UNAM cuenta con la computadora especializada Ixtli para simulación y visualización, y si están interesados en conocer esta tecnología pueden solicitar visitas guiadas demostrando su funcionamiento.

Claro, hay muchas más ideas en el tintero, y en los años por venir seguro veremos varias más. Sin embargo, no ha habido cambios substantivos en las interfaces para interactuar con una computadora de propósito general en los últimos 40 años. Me resisto a creeer que esto sea porque el modelo actual sea perfecto; como desarrolladores, tenemos la tarea de proponer, adoptar y evaluar nuevos modelos de interacción.

1 Una terminal tonta, la categoría más simple de terminal, requiere de una memoria interna a partir de unos 2KB en anillo para representar los 80x25 caracteres que puede presentar en pantalla; (no olvidemos que las primeras computadoras personales que se vendieron al público, ya en los 1970, tenían típicamente una memoria total de 4Kb)

2 Estándares como ANSI, VT100, VT220, Wyse, y muchos otros que aún a 40 años de su introducción siguen en amplio uso

( categories: )
Syndicate content