iot hacked

El viernes pasado, varias webs (twitter, github, etc) estuvieron caídas durante gran parte del día debido a un ataque DDOS contra sus servicios DNS. Lo interesante de esta noticia es que los dispositivos usados para atacar no fueron computadoras zombie, sino cámaras y grabadores de video digital conectados a internet. La internet de las cosas hackeada. No directamente relacionado con este caso, pero que puede parecer relevante ahora: Scheiner dice que alguien está aprendiendo a bloquear internet.

Califactos

Acabo de participar en la campaña de crowfunding de CALIFACTOS, de Juan. Una serie de calendarios y tarjetas navideñas realizadas a partir de objetos pictórico-sonoros que ha ido creando a lo largo de este año.

Os dejo que él mismo os los presente:

Algún amigo ha definido los CALIFACTOS como “fogonazos”, otros de “destellos fugaces”, algunos afirman que se les quedan prendidos de la memoria. Quizás se deba a que fusionan la vista con el oído y a que intento que ambos tipos de percepción se coordinen para poder ofrecer un significado que no resulta del todo evidente ni único.

No me reprimo de afirmar que están animados de un sentido libertario que resulta fácil percibir y espero que sentir. No sabría definir la libertad, pero creo que cada CALIFACTO expresa un deseo e incita a una acción comprometida con la liberación, la emancipación y la autonomía, con el anhelo de vincularnos libremente con el prójimo sin mediadores y sin coerción. A este espíritu le dedico estas emociones que pinto y escribo, y que deseo transformar en la materialidad de unos CALENDARIOS que os acompañen al menos durante el año 2017.

Si quieres calendarios y tarjetas para esta Navidad estás a tiempo de participar y apoyar económicamente el proyecto.

Por qué patrocino Eŭropano

Hoy mismo me he convertido en patrocinador de Eŭropano. El compromiso económico inicial es por 6 meses, hasta primavera de 2017. Durante ese tiempo y de manera mensual aportaré 5€ al proyecto. La razón por la que lo hago es que comparto la filosofía del proyecto: crear una esfera pan-europea de debate y acceso a información en una lengua neutral, no ligada a ningún país de la Unión Europea.

europano

La idea base es que la publicación sirva de palanca para eliminar las desigualdades de acceso a la información entre ciudadanos europeos y, por lo tanto, también de acceso a recursos económicos. Si creemos en los mercados como herramienta para el empoderamiento de personas y comunidades, debemos ser sensibles a la actual asimetría de información existente en la Unión Europea y cómo eso favorece la extracción de rentas para unos pocos.

El idioma elegido para la publicación ha sido el esperanto. Lo cierto es que yo no soy hablante de esperanto por el momento y eso requerirá un esfuerzo por mi parte para entender todo lo que se publica. Pero aunque no lea diariamente Eŭropano, el mero hecho de que exista esta iniciativa es positivo para mí y para todos los que creen en la igualdad de oportunidades.

Si queremos cambiar el status quo, no hay más alternativa que participar y ser activo. Hacerlo a través del mercado es una de los superpoderes que tenemos.

Otros patrocinios que he hecho en el pasado:

La globalización de las artes marciales

¿Por qué se popularizaron las artes marciales asiáticas pero no la esgrima o los métodos de lucha cuerpo a cuerpo occidentales?

Ésta es una de esas preguntas que lleva tiempo rondando mi cabeza y para la que nunca tuve una respuesta. Hace unos días, comentando en casa nuestra primera clase de Aikido, la conversación nos llevó a resolver este pequeño misterio.

1868

El Aikido es un arte marcial de las consideradas modernas en Japón. Aunque las diferencias entre las artes marciales japonesas tradicionales y modernas son significativas en cuanto a los métodos de entrenamiento y filosofía, la divisoria entre ellas es básicamente el año en que fueron creadas: si es posterior a 1868, es moderna. ¿Por qué ese año en concreto?

800px-Mōko_Shūrai_Ekotoba_2

Desde el siglo XII, Japón había estado bajo un dictadura militar conocida como shogunato, donde el rol del emperador era ceremonial. La sociedad se organizaba según un sistema feudal con cuatro clases sociales – por orden de importancia: samuráis, granjeros, artesanos y comerciantes. Los samuráis no sólo eran guerreros, sino también guardianes de las tradiciones y la cultura. Su rol era el de aristócratas bajo las órdenes de un señor feudal o daimyo. Durante los primeros siglos del shogunato sus habilidades marciales estuvieron muy demandadas, por lo que se convirtieron en una pieza clave de la estabilidad y poder, llegando a suponer el 10% de la población japonesa. Para hacernos una idea de su presencia en la sociedad, comparando ese porcentaje con la España de 2015, significaría que toda la gente que trabaja en agricultura/ganadería, construcción o industria sería samurái.

Sin embargo, del siglo XVII al XIX, Japón vivió un largo período de casi 250 años con relativa paz, por lo que las habilidades marciales de los samuráis fueron menos demandadas y se introdujeron medidas para restringir su influencia y privilegios. Muchos se reconvirtieron en burócratas, maestros o artistas gracias a su formación. Otros muchos, al morir sus daimyo, no encontraron un reemplazo y se convirtieron en rōnin, vagabundos errantes sin amo ni clan. Estamos en el período Edo durante el shogunato Tukogawa, una época de aislacionismo extremo (sakoku), donde se cerraron las relaciones comerciales con el exterior y entrar o salir de Japón se castigaba con la pena de muerte.

Flash forward al 8 de Julio de 1853.

gleason_1852_w750

Ésa es la fecha en la que el Comodoro Perry atraca en la bahía de Edo (actual Tokio) con una pequeña armada a vapor y el objetivo de firmar un tratado comercial. A golpe de cañón, consigue entregar una carta del presidente de los Estados Unidos dirigida al jefe de estado japonés, para negociar el tratado comercial. Los japones recogen forzados la carta y le dan largas. El Comodoro Perry sigue su ruta por Asia. Mientras, los japoneses, fortifican la isla de Odaiba para protegerse de un ataque naval. Dos años después, Perry vuelve a Japón con una armada el doble de grande para recibir una respuesta positiva y firmar el Tratado de Kanagawa. Este episodio hizo evidente que los siglos de aislacionismo habían impedido que Japón se modernizase y abrió un debate entre las élites del shogunato: ¿cómo evitar ser colonizados? Como reacción al evento, se abrieron escuelas navales y se dieron los primeros pasos hacia la industrialización, se formaron cuadros en las nuevas técnicas de la guerra, etc. Pero el mayor cambio se produjo en el marco de pensamiento de las élites: una década después de la llegada de los barcos negros de Perry a la bahía de Tokio, la ruptura es evidente y en 1868 se inicia una guerra civil conocida como la guerra Boshin, que finaliza con la dictadura militar y pone las bases del Japón moderno. 1868, la divisoria simbólica entre las artes marciales tradicionales y modernas en Japón.

En los años posteriores, conocidos como Restauración Meiji, algunos samuráis que habían apoyado al emperador reciben cargos en el nuevo gobierno como premio, pero la industrialización de la guerra y la modernización de las estructuras sociales japonesas aceleran la progresiva pérdida de privilegios e influencia de la clase samurái en su conjunto: pierden el derecho a portar sus katanas en público, el permiso a matar a otros por honor y la recepción de una paga del estado. Este período supuso un gran ERE de la clase samurái, que da sus últimos estertores en 1877, con la rebelión de Satsuma.

¿Qué hacer con los conocimientos sobre arte de la guerra que ahora nadie necesita?

aikido-osensei

Ésta fue la gran pregunta que respondieron las artes marciales modernas como el Judo o el Aikido: algunos maestros se dieron cuenta de que había un mercado para las artes marciales como programas de desarrollo personal que además pusieran en valor las tradiciones japonesas, siempre que se modernizasen las formas y el entrenamiento. Inicialmente, los compradores fueron la nueva aristocracia japonesa y ciertos sectores del gobierno que requerían sus servicios para formar a los nuevos cuerpos de seguridad con técnicas de lucha cuerpo a cuerpo.

Si trazásemos la evolución de las artes marciales europeas, no sería muy diferente: obtienen privilegios e influencia derivada de su importancia militar durante la época feudal y caen en desgracia a partir del momento en que se convierten en irrelevantes por la industrialización de la guerra y la modernización social. Sin embargo, las artes marciales japonesas -y todas las asiáticas- tuvieron la fortuna de que justo en el momento en que pasaron a tener que sobrevivir lejos de las rentas del estado, se abrió para ellos un mercado global.

Y mientras, en Occidente…

Gracias a la reciente apertura comercial, a finales del siglo XIX lo japonés está de moda. Mackintosh y McDonald diseñan con motivos japoneses las casas del té de la señorita Catherine Craston para la burguesía de Glasgow; el espíritu del Art Noveau recorre Europa con formas, colores y diseños japoneses; el gran hit de las óperas a principios de siglo XX es Madama Butterfly que bajo un relato de amor/desamor para las masas, narra una historia muy similar a la llegada de los barcos negros del Comodoro Perry a Japón y la lucha entre lo tradicional/moderno que vino después. Pero con la apertura, no sólo se abre el comercio de productos e ideas, también de personas. Aumenta la emigración a Occidente y con ella emigra también el aprendizaje de artes marciales.

artes_marciales_eua

La globalización durante el siglo XX no hace más que servir de abono a la extensión de la práctica: la segunda guerra mundial y la guerra de Vietnam ponen masivamente en contacto a los ejércitos occidentales con las prácticas militares asiáticas; la industria cinematográfica americana populariza en la segunda mitad del siglo XX las artes marciales como programa de desarrollo personal creando estrellas como Bruce Lee y series de culto como Kung fu; los gobiernos nacionales de Japón, China y Corea ven la oportunidad de usar el arte marcial como embajador de su cultura y mercado, llegando al punto de convertirlo en deporte olímpico (Japón/Judo desde el 64, Corea/Taekwondo desde el 88), etc.

TL;DR

Es un lujo que hoy en día podamos disfrutar de artes marciales como el Aikido o el Taichi. Su ritualidad y práctica codifican siglos de enseñanzas sólo matizadas por el paso del tiempo. Por otro lado, me resulta muy interesante su comportamiento interno, que se parece al de los gremios medievales que trató de recuperar Morris: la transmisión de conocimiento se basa en la práctica y la mejora continua dentro de un grupo, que comparte unos valores y código ético.

Probablemente, la principal razón por la cual todavía existen las artes marciales asiáticas es que se desmilitarizaron justo en el momento en que emergió un mercado global para los programas de desarrollo personal. Un poco de suerte y un poco de adaptación. Ahora que este pequeño misterio que me rondaba la cabeza está resuelto, ya puedo concentrarme en la práctica.

La sociedad de la reacción

A person like Martin Luther King Jr. wouldn’t be able to rally people to realize his great dream today. He would be as desperate for hourly retweets as the rest of us, gathering “likes” from followers on Facebook as a substitute for marching with them. Imagine John F. Kennedy attempting to rally national support for a decade-long race to the moon? The extreme present is not an environment conducive to building lasting movements.

But without a guiding narrative to make sense and create purpose, we end up relying too much on whatever happens to be happening in the moment. When it occurs, we over-respond to the latest school shooting. But over the long term, we lack the resolve or attention span to do anything to stop others from occurring.

How technology killed the future, Douglas Rushkoff

Por no mencionar al perro

¿Puede un libro ser a la vez una comedia de enredos, una novela de detectives, una sátira ambientada en la época victoriana y una obra de ciencia ficción? Todo eso, y más, es “Por no mencionar al perro” de Connie Willis.

De esta autora había leído Oveja Mansa. Aunque son libros y temáticas distintas, hay ciertas reflexiones compartidas; por ejemplo, las que tienen que ver con los sistemas complejos y la teoría del caos, reflexiones sobre si el progreso y la Historia es causal o casual. Quizás se deba a que las dos novelas han sido escritas durante el mismo período y Connie Willis no es inmune a la obsesividad que conlleva el aprendizaje sobre un tema (Spielberg hizo varias películas muy seguidas sobre los extraterrestres o la segunda guerra mundial, Stephenson amortizó su tiempo de investigación sobre mitología sumeria y griega en varios libros, etc). Ambas comparten también cierta manera de tejer el argumento que definiría como característica de Willis: su interés por los usos/modas/costumbres en distintos momentos históricos, las aventuras basadas en situaciones cotidianas y una escritura ligera que saca lo mejor de las comedias románticas.

¿Qué se puede decir de esta novela sin destripar la gracia del argumento?

Para empezar, que está ambientada en el año 2.057, donde existe una máquina de viajes en el tiempo que usan sólo los historiadores de Oxford porque no es rentable para nada más. Luego, que los historiadores Ned Henry y Kindle necesitan deshacer una paradoja temporal, de ésas que a la que despistas modifican el curso de la Historia de tal manera que provocan que los nazis ganen la 2ª guerra mundial, por ejemplo. Las paradojas temporales tienen un papel principal en esta novela; sin embargo, con lo que he disfrutado de verdad es con la aparición estelar de la Luftwaffe y la RAF, con el proyecto de reconstrucción de la catedral de Coventry que habría sido vendida primero a una secta espiritista y luego sustituida por un centro comercial, con el viaje que supone leer sobre la sociedad victoriana del siglo XIX durante la segunda revolución industrial o con los paseos en barco por el Támesis que son en sí mismos una road-movie.

Aunque es una novela larga con varios tirabuzones en el argumento, se hace entretenida gracias a la fina ironía y sátira que impregna el estilo de Connie Willis, así como a su capacidad para sacar jugo a los tópicos del género detectivesco y romántico. Quizás no me arrancó tantas carcajadas como en Oveja Mansa, pero sí me puso de buen humor.

Si eres fan del Ministerio del Tiempo o te gustó la película About Time, es probable que también disfrutes de esta novela donde la Historia es un personaje más. Por no mencionar al perro.

Programación de interfaces basada en componentes

O de la composición de interfaces mediante un lenguaje de programación, no un lenguaje de marcado.

En mi travesía por aprender cómo mejorar lo que hice en mi último proyecto, estoy empezando a apreciar el encaje que tienen ideas como el immediate mode, las funciones puras y la inmutabilidad. Conceptos que transcienden modas y que, al entender su utilidad y trade-offs, se introducen en el conjunto de herramientas que tenemos a nuestra disposición, sea cual sea el contexto en que programamos.

Hay otro concepto al que recientemente le estoy prestando atención: programación de interfaces basada en componentes.

¿En qué consiste?

En la creación de elementos reutilizables que sean autosuficientes. Es decir, estables por sí mismos y que no dependan de estado global.

components_before components_after
Lo que hacemos ahora Lo que necesitamos hacer

Es muy interesante comparar cómo diversas herramientas proponen la creación (o no) de componentes. La selección tecnológica es, en sí mismo, un tema con muchos matices y tonalidades y existen diversas aproximaciones para comparar toolkits de programación. Algunas aportan algo, otras no y otras depende.

Por ejemplo, a la hora de comparar dos toolkits líderes de sus respectivos sectores como Wicket y React podríamos hacerlo de la siguientes maneras:

Sin embargo, si los comparamos en términos de cómo componen la interfaz, vemos que su aproximación es similar: proponen crear componentes que encapsulen conjuntamente HTML, CSS y JavaScript. ¿Cómo lo hacen? Tanto Wicket como React crean los componentes mediante un lenguaje de programación (Java/JavaScript) y no mediante un lenguaje de marcado (HTML).

  • Componente en Wicket. En Wicket, la unidad mínima de reutilización es el Panel, que consiste en varios archivos: panel.java, panel.html y opcionalmente otros de localización como panel.properties.
  • Componente en React. En React, el componente es un archivo JavaScript que devuelve código HTML. JSX es únicamente azúcar sintáctico que ayuda a que el código JavaScript sea más expresivo.

Esta aproximación los diferencia de otros toolkits como Angular, Polymer, JSP o Mako, que serían ejemplos de lo contrario: la composición de la interfaz se hace mediante un lenguaje de marcado -HTML- o derivativos que compilan a él.

¿Esto supone una mejora?

La respuesta rápida: sí, porque en un lenguaje de programación tienes a tu disposición 50 años de investigación en computer science, destilados con más o menos suerte. Hombros de gigantes sobre los que mirar más lejos.

La respuesta más elaborada: las interfaces son sistemas complejos, necesitamos subcomponentes para simplificar su creación y mantenimiento. Hay dos áreas donde un lenguaje de programación supera al de marcado para crear subcomponentes: encapsulación y expresividad.

Encapsulación

La encapsulación consiste en la creación de elementos que podamos (re)usar sin la obligación de entender sus propiedades internas, ni de empezar todo desde cero cada vez. En un lenguaje de programación tenemos herramientas para encapsular elementos y funcionalidades como paquetes, módulos, clases, funciones, herencia, mixins, patrones de diseño, etc. Por el contrario, en un lenguaje de marcado como HTML, las opciones son inexistentes.

Iniciativas como WebComponents se han creado 20 años después del propio HTML. Son bienvenidas, pero no podemos obviar el elefante en la habitación: sólo nos ofrece la creación de paquetes, no todo lo demás. En Wicket y React los componentes son elementos que están programados en Java/JavaScript y, por lo tanto, podemos hacer con ellos lo que normalmente haríamos con cualquier otro trozo de código: herencia, composición, aplicar patrones de diseño, etc.

Expresividad

La expresividad consiste en la capacidad de programar los distintos matices que deseamos. En un lenguaje de programación tenemos a nuestra disposición mecanismos como tipos de datos, control de flujo, inversión de flujo, bucles, paso de mensajes, etc. HTML no tiene nada de esto.

Los toolkits que pretenden componer mediante un lenguaje de marcado -JSP en Java, Mako en python, etc- no poseen esa expresividad. Para solventarlo, tratan de integrar parte de ella en un lenguaje propio que compila a HTML: un sistema de plantillas. Un ejemplo típico que casi todos los sistemas de plantillas poseen son algunas construcciones para controles de flujo y bucles. Por ejemplo, en JSP:

<c:when test="${isThisVariableTrue}">
 <h1><fmt:message key="Title" /></h1>
 <c:if test="${isThisOtherVariableTrue}">
 <fmt:message key="showMessage" />
 <c:out value="${value}" />
 </c:if>
 <c:if test="${isThisOtherSecondVariableTrue}">
 <fmt:message key="aDifferentMessage" />
 <c:out value="${aDifferentValue}" />
 </c:if>
</c:when>

También necesitan crear mecanismos para pasar información del código a la plantilla y suelen ofrecer nuevos tags HTML para realizar acciones que HTML no permite. Interacciones que cualquier lenguaje de programación incluye por defecto pero que un sistema de plantillas integra con esfuerzo, limitaciones y a costa de aprender una nueva sintaxis no reutilizable en otros contextos. Para controlar la complejidad necesitamos más expresividad que la que nos aportan bucles y condicionales. Si lo único que puedes utilizar es un martillo, todos los problemas te parecerán clavos.

Conclusión

Sería simplista decir que Wicket y React se han convertido en líderes de sus respectivos sectores únicamente por la propuesta de creación de interfaces mediante componentes. Es, sin embargo, un fundamento que comparten y plausible para explicar por qué React tiene éxito y Polymer no: como la productividad aumenta al usar esta aproximación, se acaba extendiendo por microdecisiones de agentes interrelacionados que buscan su propio beneficio.

Al pivotar la construcción de componentes sobre un lenguaje de programación y no sobre un lenguaje de marcado tenemos a nuestra disposición todas las herramientas de encapsulación y expresividad disponibles en el lenguaje, lo que facilita domar la complejidad inherente a la creación de interfaces. El aumento de productividad es de órdenes de magnitud.

Para entender en toda su complejidad los efectos del cambio, conviene releer parábola de los relojeros.

Dos ideas funcionales

En la evolución de cómo se hacen aplicaciones web, la mutación principal del ciclo anterior habría sido la separación API/interfaz. En el actual, apostaría que lo fundamental se deriva de que el ecosistema JavaScript (tanto el lenguaje como las librerías a su alrededor) ha interiorizado dos ideas del mundo de la programación funcional: las funciones puras y la inmutabilidad. Esta hipótesis serviría para explicar, por ejemplo, la popularidad de React y Redux que no son más que la aplicación de estos conceptos a la creación de interfaces y la gestión del estado.

Modern Layouts

Jen Simmons, editora del podcast The Web Ahead, presentó en el último AnEventApart una charla sobre la evolución de los layouts para la web y las nuevas posibilidades que existen. Muy recomendable en conjunción con los experimentos y demos que pueden verse en The Layout Ahead.

Xerox Star

El Xerox Star fue el primer ordenador moderno que salió a mercado. Lanzado en 1981, definió una nueva relación con los ordenadores que prevalece todavía hoy en los sistemas que usamos a diario. Sin embargo, fue un fracaso comercial.

El Xerox Star fue el primer ordenador moderno que salió a mercado. Lanzado en 1981, definió una nueva relación con los ordenadores que prevalece todavía hoy en los sistemas que usamos a diario.

El contexto

En los 70, las computadoras estaban reservadas a entornos militares y universitarios, tenían el tamaño de una habitación y eran sistemas de tiempo compartido: un ordenador central al que se conectaban “terminales tontos”. Las interfaces eran orientadas a texto.

A mediados de la década, el signo de los tiempos apuntaba ya en otra dirección: la de las computadoras personales. Xerox, que era una de las mayores compañías tecnológicas del mundo gracias al negocio de copiadoras, no era ajena a ese ambiente y su visión era que los ordenadores podrían automatizar la oficina: fundamentalmente ayudando en la creación de informes y documentos – que se podrían imprimir con sus copiadoras, claro. Su visión -y la de muchos otros- era que el negocio estaba en el WordProcessing no en el DataProcessing.

Rank_Xerox_8010+40_brochure_front

Los anuncios del  Xerox 8010 InformationSystem –como era conocido el Star en el mercado- captan muy bien esa atmósfera. El que vemos a continuación es uno de los primeros que le muestran al público un ordenador con ventanas, iconos y otro tipo de metáforas referidas al escritorio (carpetas, archivadores, impresoras, etc):

Xerox PARC

En Xerox PARC, el centro neurálgico de Xerox, se reunía la gente que había estudiado y trabajado con los pioneros de la generación anterior (Douglas Englebart e Ivan Sutherland) para investigar y aterrizar qué podía significar eso de la automatización de la oficina. Un caldo de cultivo que favoreció multitud de invenciones: desde la impresión por láser, hasta el estándar de comunicaciones Ethernet, incluyendo la interfaz gráfica de usuario y el primer lenguaje de programación orientado a objetos, SmallTalk. Incluso habían construido un prototipo de “ordenador personal“: el Xerox Alto, bajo el tutelaje del Learning Research Center liderado por Alan Kay y que pretendía concretar las ideas en torno al Reactive Engine o el Dynabook.

Merece la pena recordar todo el background, ideas y trabajo previo que recoge el Star con un gráfico realizado por los propios diseñadores para la retrospectiva del producto que publicaron en 1989.

star_influences

Se puede ver en este gráfico también las influencias sobre los productos posteriores, que no son exclusivamente de ideas, sino que vienen muchas veces derivadas de personas que cambian de equipos: Larry Tesler que se va a Apple para trabajar en el diseño del Lisa, donde también estuvo Tom Malloy creando el LisaWrite, Simonyi a Microsoft para crear el Word continuando así el trabajo que él mismo había hecho con Lampson en la aplicación Bravo, el primer editor WYSIWYG y un largo etc.

El Xerox 8010 Information System

Para llevar a mercado esas invenciones, los directivos de Xerox decidieron crear el SDD (Systems Development Department), una división interdepartamental que contaba con 2 centros situados en California: Palo Alto y El Segundo. Dirigidos por David Liddle, el SDD inició su tarea en el verano de 1978 y tres años después, en 1981, el Star se presentó al público.

Esta división, además de nutrirse de muchos ingenieros de PARC, también contrató gente externa como Bill Verplank, un consultor de lo que entonces se conocía como Human Factors. Liddle describe el proceso de trabajo como:

It began with task analysis, looking at a fairly wide range is users. Next came the job of developing scenarios for uses of the imagined product based on the task. Then, it proposed a model for a graphical user interface, carefully distinguishing three aspects: the display of information, the control or command mechanisms and the user’s conceptual model.

Es decir, trabajaron con conceptos como análisis orientado a la tarea, design personas, prototipos como herramienta de selección de conceptos, etc.

El resultado fue un ordenador que costaba, consumía y pesaba un tercio menos que cualquier otro de la época:

El diseño de interacción

Una de las cosas verdaderamente únicas del Star fue proponer el escritorio como metáfora central para organizar los elementos y sus interacciones. Sorprende descubrir hasta qué punto se adhiere a esa metáfora. Vale la pena revisar videos y capturas de pantalla para descubrir pequeñas joyitas y grandes ideas que, en cierta medida, muchos sistemas operativos modernos están tratando de recuperar.

Algunas cosas que me han parecido curiosas del sistema y que son todavía hoy novedosas:

— Objetos y propiedades, no menús

El sistema es una verdadera interfaz orientada a objetos: cada elemento es un objeto y, por lo tanto tiene ciertas propiedades. Los objetos de texto (carácter, párrafo, etc) tienen propiedades de alineación, tipográficas, etc; los gráficos tienen como propiedades los datos que representan, visualización, colores, etc.

Por ejemplo, al abrir el editor de documento no hay menú, es una hoja en blanco. Se empieza a escribir y, para poner algo en cursiva no seleccionamos una herramienta de un menú una sino que se selecciona lo que se quiere modificar y se abre su panel de propiedades. De alguna manera, la no existencia de menús refleja la no existencia de estado o variables globales en la aplicación. Una interfaz orientada a objetos pura.

text_property_sheet

— Comandos generales

No tener un menú tiene limitaciones, ya que hay ciertas acciones que son entre objetos: buscar, copiar, mover, etc. La manera en que resolvieron esto fue creando comandos generales que tenían sus propias teclas en el teclado del Star.

Estos comandos son usados ampliamente en el sistema y mantienen su coherencia a lo largo de los diferentes contextos: mover, por ejemplo, puede significar tomar una frase de un párrafo y llevarla a otro; pero también significa lanzar una impresión si se mueve un documento al icono de la impresora.

— Orientación a la tarea: no se abren aplicaciones, sino documentos

El Star no tenía iconos para aplicaciones, esto fue algo que se introdujo en sistemas posteriores. Por otro lado, como dije anteriormente, funciones como la impresión o el envío de un mail se tratan como cualquier otro elemento: existe la impresora y la bandeja de salida de mail como objetos independientes; para imprimir se copia el documento sobre el objeto impresora; para enviar un mail se copia el documento sobre el objeto bandeja de entrada. La diferencia es sutil y separa la metáfora del escritorio (donde sólo hay documentos) de la metáfora del banco de trabajo (donde hay herramientas que aplicamos sobre un elemento).

Así lo definieron los propios diseñadores del Star en 1989:

«Having windows and a mouse does not make a system an embodiment of the Desktop metaphor. In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs. They do not “invoke a text editor”, they “open a document”. The system knows the type of each file and notifies the relevant application program when one is opened.

Most systems, even many windowed ones, use a Tools metaphor, in which users deal mainly with applications as tools: users start one or more application programs (e.g., word processor, spreadsheet), then specify one or more data files to edit with each. Such systems do not explicitly associate applications with data files; the burden of doing that — and of making sure not to try to edit a spreadsheet file with the text editor or vice-versa — is on users. Different kinds of files are distinguished by user-convention, usually via filename extensions (e.g., memo.txt). Star relieves users of the need to keep track of which data file goes with which application.

SunView is an example of a window system that is based upon the Tools metaphor rather than the Desktop metaphor. Its users see a collection of application program windows, each of which is used to edit certain files. Smalltalk-80, Cedar, and various Lisp environments also use the Tools metaphor rather than the Desktop metaphor.

This is not to say that the Desktop metaphor is superior to the Tools metaphor. The Desktop metaphor was intended for office automation and publishing. It may not be appropriate for other applications (e.g., software development). However, it can be argued that orienting users toward their data rather than toward application programs and employing analogies with the physical world are useful techniques in any domain

— Y mucho más

Para una revisión de las interfaces del Star es necesario desaprender lo que uno sabe de las interfaces actuales. Conceptos como el WYSIWYG fueron usados en un sistema comercial por primera vez aquí, también el uso de teclados virtuales para la introducción de fórmulas o la escritura en múltiples idiomas (incluyendo los RTL). Podríamos hablar también de cómo el Star usaba técnicas como el progresive disclosure, direct manipulation, etc.

Es muy recomendable revisitar los videos del producto y abrir bien los ojos y la mente.

¿Por qué no tuvo éxito el Star?

Sin embargo, a pesar de lo maravilloso del producto, el Star no fue un éxito comercial, como sí lo fueron sus inmediatos competidores que copiaron sus ideas. ¿Qué falló?

Jobs argumenta que Xerox sufrió lo que otras compañías con un cuasi-monopolio: la gente que influye en el futuro de la compañía era gente que veían de las posiciones de ventas y márketing, no los de producto. Debido al cuasi-monopolio, el common wisdom de la compañía es que lo que la hace más exitosa no es crear una nueva copiadora, sino aumentar el mercado mediante márketing y ventas. De esa manera, progresivamente la gente de producto queda relegada de los puestos de decisión hasta que, las compañías, en cierta manera, olvidan cómo se hacen buenos productos.

Complementariamente a lo que dice Jobs hay otras razones de peso para el fracaso, algunas de las cuales eran ya claras en 1989 para el equipo de diseñadores del Star:

  • Prestar atención a las tendencias de la industria y reducir los tiempos de salida del producto.

«At the time they were developed, these technologies were unique in the industry. Xerox elected to keep them proprietary for fear of losing its competitive advantage. With hindsight, we can say that it might have been better to release these technologies into the public domain or to market them early, so that they might have become industry standards. Instead, alternative approaches developed at other companies have become the industry standards.»

  • Prestar atención al mercado: el hecho de haber sido una plataforma cerrada les impidió ser beneficiarios de la innovación que estaban realizando otros.

«The personal computer revolution has shown that it is futile to try to anticipate all of the applications that customers will want. Star should have been designed to be open and extensible by users from the start, as the Alto was. In hindsight, extensibility was one of the keys to the Alto’s popularity. The problem wasn’t that Star lacked functionality, it was that it didn’t have the functionality customers wanted. An example is the initial lack of a spreadsheet application. The designers failed to appreciate the significance of this application, which may have been more important even than word-processing in expanding the personal computer revolution beyond engineers and hobbyists into business. Eventually realizing that Star’s closedness was a problem, Xerox replaced it with ViewPoint, a more “open” system that allows users to pick and choose applications that they need, including a spreadsheet and IBM PC software. Apple Computer learned the same lesson with its Lisa computer, and similarly replaced it with a cheaper one having a more open software architecture: Macintosh.

  • Conocer el mercado al que te diriges.

«Star’s initial per-workstation price was near that of time-shared mini-computers, dedicated word-processors, and other shared computing facilities. Star was, however, competing for desktop space with micro-computer-based PCs.»

En definitiva, el fracaso de Xerox parece que tuvo más que ver con la desalineación con el mercado que con las bondades del producto. Sin embargo, hablar con la sabiduría que nos da la perspectiva histórica es ventajoso. Muy pocos podrían haber predicho que una aplicación con el VisiCalc, crearía el término Killer Application y convertiría un mercado para ingenieros amateurs en uno de computadores personales para profesionales del conocimiento, creando y dando el pistoletazo de salida a la carrera por el dominio del nuevo mercado.