Modelo cibernético del liderazgo

Una presentación sobre los principios del liderazgo (poder = conocimiento, reglas escritas, normas culurales) desde la teoría de los sistemas auto-regulados. O "cómo liderar un equipo en proyectos creativos".

A Socio-Cybernetic Model for Designing Leadership in the UX Community

View more presentations from Will Evans.

Good Bad Applications

Applications are bad

- Data should not be held ransom inside the walled garden of an application.
- It should be freely editable through the standard Operating System tools,
- and easy to export and import from the application repositories.

Applications, as designed today, tend to make all of the former difficult.


Applications are good
- Applications gather a collection of tools related and suitable to one purpose.
- They organize information and give name to concepts useful to accomplish user goals.
- They make easy for the user to follow task flows pertinent to the goals.
- They allow the user to learn about new concepts in the problem domain, new ways to manage information, and which tools are available in the system for the domain

The concept of an Application is a good information architecture and design pattern for well known problems, where most user needs are anticipated by the designer. If only they weren't niches inside which data gets trapped, they would be a good way to design user interactions!

Wharton’s four questions for user-centered HCI

Tale of two tutorials

4 questions for a cognitive walkthrough:

• How do users know their goal is attainable?
• How do users know what to do?
• How will users know they have done the right thing?
• How will users know they have attained their goal?

Now this may come as something of a surprise if you are primarily involved in HCI, but these questions are profound to software and web site developers since most will never have considered user interaction in this way

Objetos más rápidos que la luz

La teoría de la relatividad normalmente se interpreta como que "ningún objeto puede moverse más rápido que la luz...". Sin embargo en la explicación popular se omite que la frase se refiere a objetos "...dentro del mismo marco de referencia" (inercial).

En realidad la teoría (general) de la relatividad sí que admite objetos que se separan más rápido que la luz - de hecho las galaxias más lejanas en el universo observable estarían alejándose de nosotros a una velocidad mayor que c.

La clave para entender esta (aparente) paradoja en la teoría de la relatividad se explica a fondo en el artículo "Expanding Confusion: common misconceptions of cosmological horizons and the superluminal expansion of the Universe" por Tamara M. Davis y Charles H. Lineweaver:
http://arxiv.org/abs/astro-ph/0310808

Aparte de un detallado tratamiento matemático (también incluido en el artículo), la explicación intuitiva de la discrepancia está en que la "imposibilidad de superar c" es sólo una limitación de la teoría de la relatividad especial (es decir, en cuerpos moviéndose dentro del mismo sistema inercial - mismo marco de referencia).

Esto afecta a distancias cósmicas locales, pero no a los objetos más lejanos del universo - que (según lo que he entendido del artículo) pertenecerían a marcos inerciales distintos al nuestro y por tanto no están afectados por esta limitación de su velocidad respecto a nosotros.

El artículo explica cómo la relatividad general es coherente con dichas velocidades superlumínicas. En principio se suele usar la idea de que la expansión del universo puede hacer alejarse los objetos más rápido de lo que la luz viaja "dentro del universo", pero esta explicación sólo desplaza el problema al de entender qué significa eso de la "expansión del universo".

El problema de interpretación surge cuando los físicos intentan hacer divulgación y explicar en términos no matemáticos la explicación intuitiva de dichas fórmulas. Muchas veces, hasta los profesionales se hacen un lío y usan fórmulas de relatividad especial en sitios donde sólo tiene sentido la general (por ejemplo medir la velocidad de quásares con efecto Dopler, asumiendo que tiene que ser sublumínica). En algunas interpretaciones de la teoría esto es necesario, pero en otras no lo es. Los autores achacan estos problemas de intuición, incluso entre profesionales, a que hasta hace muy poco no se disponía de una medición precia de la radiación del fondo de microondas, y sin dicha precisión los márgenes de error eran demasiado amplios para que estas distinciones teóricas fueran relevantes en la práctica observable.

El artículo aporta pruebas empíricas que dan indicios de que las interpretaciones superlumínicas podrían ser correctas (por ejemplo, hay galaxias con mediciones de desplazamiento al rojo que - bajo la relatividad general estándar, sin modificaciones para abordar el fenómeno - corresponderían a galaxias alejándose a velocidad superlumínica).

Finalmente, el artículo desmonta varias de esas "explicaciones intuitivas" erróneas (misconceptions) sobre las interpretaciones de la teoría. Sería incorrecto decir, por tanto, que:

- Mito 1: la velocidad de alejamiento no puede superar la velocidad de la luz. (Pista: sí puede)
- Mito 2: la inflación tras el Big Bang pudo causar la expansión superlumínica del universo, pero la expansión normal no puede. (Pista: también puede)
- Mito 3: existen galaxias alejándose a una velocidad superlumínica, pero nos resulta imposible verlas. (Pista: sí podríamos ver - algunas de ellas/todas/ninguna, en función del modelo cosmológico utilizado).

Y por último una ambigüedad: la forma de representar los horizontes "fundamentales" en los diagramas espaciotemporales introduce problemas conceptuales, ya que el horizonte de Hubble / el horizonte de eventos / y el horizonte de partículas no son necesariamente iguales (tienen distintas definiciones), y sólo serían físicamente idénticos en algunos modelos cosmológicos - pero no en todos.

Riqueza militar y paz de civilizaciones

La fracción militarizable de la riqueza

Insight sobre la relación entre la potencia militar naval y las rutas comerciales - el equilibrio mundial actual se debería a que la principal tecnología militar actual está conectada con la prosperidad comercial y el avance científico.

Mientras la guerra terrestre es intensiva en mano de obra, y depende de la capacidad del Estado para efectuar grandes conscripciones, la guerra en el mar es intensiva en capital.[...]La naturaleza benigna de las talasocracias en la Historia es inevitable: el poder sobre el mar depende no del número de hombres o de los dominios de un Estado, sino de la calidad y abundancia de sus barcos, y los barcos son la herramienta del comercio, es decir, de la prosperidad y la fraternidad internacional.
...

Si nuevas técnicas vuelven a desacoplar la eficacia militar del aumento del nivel de vida y complejidad social, la barbarie podría volver a triunfar.

..y .el equilibrio podría estar cambiando.

Some intuitions on Monads

Remember your first lesson in structured programming, when the teacher insisted there where 3 operations for program structure: the conditional (if), loop (while), and sequence (;) operators. Conditionals choose between two alternate control sequences; loops repeat a sequence; and 'sequence' itself defines the order in which simple operations are chained together.

Did you mutter to yourself then, "how can 'sequence' be an operator and not just, well, how the program is laid out in the file?" Well, fact is you really can think of sequence as an explicit operator. And monads are a way to overload that operator, in the OOP sense of operator overloading.

If you have defined a monad in a functional program, you can use it to build a sequence of operations, just like you would in an imperative program. But you can actually change the meaning of the composition in the sequence: every step of your program, the logic in the monad is activated and it decides how (and if) it should perform the next step.

See this example from Monads in Ruby (with nice syntax!):

def with_failable_rbinding(first_divisor)
    with_monad Failable do
        val1 =xx fdiv(2.0, first_divisor)
        val2 =xx fdiv(3.0, 1.0)
        val3 =xx fdiv(val1, val2)
        val3
    end
end

Here you have a do-block containing a sequence of divisions composed using the special monadic assignment =xx. Everything executed within the block is handled by the Failable monad, wich is programmed to return a special non-numeric Failure value when a division by 0 is performed:

puts fdiv_with_binding(1.0)
=> Success(0.666666666666667)

puts fdiv_with_binding(0.0)

=> Failure(cannot divide by zero)

For every side effect in traditional imperative programming (control of errors, concurrency, input/output, commit/rollback of the whole application state, non-determinism... and some more) you can get some specific logic added for it, anytime, for free, without any syntactic complexity other than the sequence operation. Better yet, you can change the allowed side effects without actually changing a single line of your imperative procedure, just by redefining the logic encapsulated in the monad that glues the statemens in the procedure together.

See some more of my intuitions on monads here.

Idea para un idioma de programación universal usable

Idea clave: reificar los conceptos de "enlace" y "colección".

Explicación:
Igual que la web revolucionó el almacenamiento de información gracias a hacer visible la idea del "enlace" entre documentos, se podría revolucionar la Programación por el Usuario Final creando una entidad "enlace" y otra "colección" que funcionen:

• como entidades genéricas
  
• con una "API" visual sencilla y homogénea
• que funcionen SIEMPRE, sobre cualquier otra entidad manejable por el usuario (ésto es lo más difícil, haría falta un clasificador universal de información de usuario tipo Nepomuk + URIs).

¿Por qué se puede revolucionar la programación por parte de los usuarios? Ahora no existe una forma sencilla de automatizar tareas:

• los lenguajes de programación son demasiado abstractos - la separación código/datos es un salto conceptual difícil para no programadores. (El caso más sencillo, el Apple Automator es un lenguaje de scripting, es difícil hacer flujos más allá de lo estrictamente trivial)
• el Excel es el paradigma más programable a nivel de usuario, pero sólo maneja relaciones numéricas - y no es aplicable a los objetos de interfaz, sólo a bases de datos.

¿Cómo se programaría con "enlaces" y "colecciones"?

• Un Enlace entre dos objetos permite definir acciones asociadas a eventos (desde un extremo "Origen" está accesible el otro "Destino") con un esquema mental sencillo. Como los enlaces se pueden aplicar a objetos de la interfaz, los enlaces se pueden usar para acceder a información no visible en el estado actual de la máquina.

• Una Colección permite automatizar una tarea repetitiva (sin las complicaciones del uso de bucles): aplicar una acción a todos los objetos de la colección, o a todos los que quedan tras aplicar un filtro.
  

• Tanto Enlaces como Colecciones soportan la "programación basada en ejemplos": los programas se pueden definir sobre datos reales, no como una entidad abstracta separada ("programa") sino como una serie de ediciones de manipulación directa sobre información. El feedback es mucho mayor que con un entorno/lenguaje de programación.
• Ver la "metáfora del pintor" para crear agrupaciones automáticas:
• • Now, for the following let's think of nodes being white bricks placed in an ordered row on the floor. These bricks can be painted with one (or even several – think: spotty!) colors. The color indicates the element by which the bricks should be grouped.
  • The grouper does one very simple thing: It wraps all adjacent, likewise colored nodes in a parent element (think of this being some kind of bag) that has the same name as the color of the nodes it wraps.So the essential part to be done beforehand is to color the nodes in the desired way. This is a two-step process: First, you need to check the role of each node as far as grouping is concerned and assign it that role by placing a painter on it that knows how to go about painting for this specific role. Second, the painting is actually performed.

Types of activities in cognitive dimensions

Cognitive Dimensions tutorial

Tipos de tareas - tipos de actividades - task / activity types:

Los 4 tipos principales de actividades son:

• incrementation: adding a new card to a cardfile; adding a formula to a spreadsheet

• transcription: copying book details to an index card; converting a formula into spreadsheet terms
  

• modification: changing the index terms in a library catalogue; changing the layout of a spreadsheet; modifying the spreadsheet to compute a different problem
  

• exploratory design typographic design; sketching; programming on the fly (‘hacking’)

Las 4 categorías de actividades de usuario

• Aumento: introducción de nueva información no existente en el sistema.

Añadir un nuevo registro a una tabla; añadir una fórmula a una hoja de cálculo.

• Transcripción: transformación de un tipo de información otro tipo de información diferente, manteniendo esencialmente los mismos contenidos.

Copiar de detalles de un libro a una tarjeta de índice; traducir una fórmula matemática a una en términos de la hoja de cálculo.

• Modificación: alteración de los contenidos de la información.

Cambiar los términos del índice en un catálogo de la biblioteca; cambiar la disposición de una hoja de cálculo; modificar la hoja de cálculo para calcular un problema distinto.

• Diseño exploratorio: manipulación de la información con un objetivo, pero sin conocer la forma final deseada.

Diseño tipográfico; dibujar bosquejos o esquemas; programación “sobre la marcha” (`hacks’)


Cognitive Dimensions tutorial

Functional vs Imperative Programming

In imperative programming, procedures are structured around data transformations. In functional programming, functions are structured around data dependencies.

The tricks you learn to program the imperative way are different to those you use for funtional programming, that's why it's difficult for IP programmers to do the switch to FP. Not because FP is inherently more difficult, but because you lose your expertise and start again as a beginner.

Mónadas: intuiciones

En programación funcional:
- una Monad es un módulo funcional con estilo Inversion of Control. (Es decir, se pueden construir funciones que usan la mónada como parámetro, y la ejecución de la mónada llama a estas funciones en el orden adecuado).
- el type constructor M es el functor usado para construir expresiones del tipo monádico. (La "declaración" del tipo monádico).
- la unit function transforma un valor normal en un valor del tipo monádico (el "cuerpo" del constructor de tipo monádico).
- el método Bind (>>) de una mónada recibe argumentos, y una continuation. (Es decir, para construir la definición de la mónada tenemos que indicar cómo se combinan las funciones a las que hay que llamar, y para controlar ese flujo utilizamos un estilo de programación con continuations).

Considerando lenguajes como Nombre Verbo: Si en programación orientada a objetos los objetos son nombres (son una abstracción de un dato o conjunto de datos reutilizables), en funcional las mónadas se podrían considerar verbos (son abstracciones de computaciones reutilizables).

Me autocito de la Wikipedia:

Intuitively, the type constructor would correspond to a type declaration, the unit function takes the role of a constructor method in OOP, and the binding operation contains the logic necessary to execute its registered callbacks (the monadic functions).

Formally, a monad is constructed by defining two operations bind and return and a type constructor M that must fulfill several properties to allow the correct composition of monadic functions (i.e. functions that use values from the monad as their arguments). The return operation puts a value from a plain type into a monadic container of type M. The bind operation performs the reverse process, extracting the original value from the container and passing it to the associated next function in the pipeline.