En el diseño de interfaces de usuario y de software , [1] el principio del mínimo asombro ( POLA ), también conocido como principio de la mínima sorpresa , [a] propone que un componente de un sistema debe comportarse de la manera que la mayoría de los usuarios esperan que se comporte, y por lo tanto no asombrarlos ni sorprenderlos. El siguiente es un corolario del principio: "Si una característica necesaria tiene un alto factor de asombro, puede ser necesario rediseñar la característica". [4]
El principio se ha utilizado en relación con la interacción informática al menos desde la década de 1970. Aunque se formalizó por primera vez en el campo de la tecnología informática, el principio se puede aplicar ampliamente en otros campos. Por ejemplo, en la redacción , una referencia cruzada a otra parte de la obra o un hipervínculo deben redactarse de manera que indiquen con precisión al lector qué esperar.
Una referencia temprana a la "Ley del Mínimo Asombro" apareció en el PL/I Bulletin en 1967 (PL/I es un lenguaje de programación lanzado por IBM en 1966). [5] A fines de la década de 1960, PL/I se había vuelto tristemente célebre por violar la ley, [6] por ejemplo porque, debido a las reglas de conversión de precisión de PL/I, [7] las expresiones 25 + 1/3y 1/3 + 25producirían un error fatal o, si se suprimían los errores, 5.33333333333 en lugar del 25.33333333333 correcto. [8]
La ley apareció escrita en su totalidad en 1972:
En el caso de aquellas partes del sistema que no se pueden ajustar a las peculiaridades del usuario, los diseñadores de un lenguaje de programación de sistemas deben obedecer la “Ley del Mínimo Asombro”. En resumen, esta ley establece que cada construcción del sistema debe comportarse exactamente como su sintaxis lo sugiere. Se deben seguir las convenciones ampliamente aceptadas siempre que sea posible y las excepciones a las reglas previamente establecidas del lenguaje deben ser mínimas. [9]
Una formulación clásica es: “Las personas son parte del sistema. El diseño debe coincidir con la experiencia, las expectativas y los modelos mentales del usuario ”. [10]
El principio apunta a aprovechar el conocimiento existente de los usuarios para minimizar la curva de aprendizaje , por ejemplo, diseñando interfaces que toman prestado en gran medida de "programas funcionalmente similares o análogos con los que es probable que sus usuarios estén familiarizados". [2] Las expectativas de los usuarios a este respecto pueden estar estrechamente relacionadas con una plataforma o tradición informática particular . Por ejemplo, se espera que los programas de línea de comandos de Unix sigan ciertas convenciones con respecto a los conmutadores , [2] y se espera que los widgets de los programas de Microsoft Windows sigan ciertas convenciones con respecto a los atajos de teclado . [11] En entornos más abstractos como una API , la expectativa de que los nombres de funciones o métodos coincidan intuitivamente con su comportamiento es otro ejemplo. [12] Esta práctica también implica la aplicación de valores predeterminados sensatos . [4]
Cuando dos elementos de una interfaz entran en conflicto o son ambiguos, el comportamiento debería ser el que menos sorprenda al usuario ; en particular, un programador debería tratar de pensar en el comportamiento que menos sorprenderá a alguien que usa el programa, en lugar de aquel comportamiento que es natural a partir de conocer el funcionamiento interno del programa. [4]
La elección del comportamiento "menos sorprendente" puede depender de la audiencia esperada (por ejemplo, usuarios finales , programadores o administradores de sistemas ). [2]
Los sitios web que ofrecen atajos de teclado a menudo permiten presionar ?para ver los atajos disponibles. Algunos ejemplos incluyen Gmail , [13] YouTube , [14] y Jira . [15]
En los sistemas operativos Windows y algunos entornos de escritorio para Linux , la tecla de función normalmente abre el programa de ayuda de una aplicación . Un atajo de teclado similar en macOS es + + . Los usuarios esperan una ventana de ayuda o un menú contextual cuando presionan las teclas de atajo de ayuda habituales. Es probable que el software que en su lugar utiliza este atajo para otra función cause asombro si no aparece ninguna ayuda. [16]F1 ⌘ Command⇧ Shift/
La biblioteca estándar de un lenguaje de programación suele proporcionar una función similar al pseudocódigo , que crea un entero legible por máquina a partir de una cadena de dígitos legibles por humanos . El radix convencionalmente tiene como valor predeterminado 10, lo que significa que la cadena se interpreta como decimal (base 10). Esta función normalmente admite otras bases, como binaria (base 2) y octal (base 8), pero solo cuando se especifican explícitamente. En una desviación de esta convención, JavaScript originalmente tenía como valor predeterminado la base 8 para las cadenas que comenzaban con "0", lo que causaba confusión entre los desarrolladores y errores de software . [17] Esto se desaconsejó en ECMAScript 3 y se eliminó en ECMAScript 5. [18] ParseInteger(string, radix)
Algunas comunidades de desarrollo como FreeBSD [19] utilizan POLA como una de las pautas que definen lo que constituye una experiencia de usuario sorprendente.
¿Podría haber un alto factor de asombro asociado con la nueva característica? Si el usuario aplica incorrectamente una característica por accidente y provoca lo que le parece un resultado impredecible, esa característica tiene un alto factor de asombro y, por lo tanto, es indeseable. Si una característica necesaria tiene un alto factor de asombro, puede ser necesario rediseñar la característica.
me comentó una vez un amigo mío (debe haber sido a fines de los años 1960), más allá de lo que se pueda decir al respecto, hay una cosa que el PL/I definitivamente no es, y es "el lenguaje del menor asombro".
PL/I es el peor ejemplo aquí; está plagado de construcciones que no hacen lo que el programador piensa, como lo ejemplifica la división FIJA.
Desafortunadamente, la expresión '25 + 1/3' da como resultado 5.33333333333333
Para que el programador que no utiliza PL/I no llegue a la conclusión errónea de que PL/I no tiene defectos, considere los siguientes ejemplos de la hostilidad de PL/I. Las reglas para la conversión de tipos en PL/I son suficientes para provocarles úlceras a los programadores. ¿Qué otro lenguaje produciría un error fatal al evaluar la expresión (25 + 1/3)? (Igual de malo, si suprime la comprobación de errores, el resultado de evaluar la expresión es 5.3333...)
PL/I es infame en este sentido, ya que convierte casi cualquier tipo en cualquier otro tipo, a veces con resultados sorprendentes. Considere la expresión 1/3 + 25. En PL/I esta expresión tiene el valor 5.33333333333. ¿Por qué? Un tercio se calcula con 15 dígitos de precisión, 14 a la derecha del punto decimal. Luego, 25 se convierte a la misma precisión, perdiendo el dígito más significativo 2! Esto genera un error en PL/I, pero el valor predeterminado es ignorarlo. Esto apareció impreso por primera vez en Barron 1968, donde se presenta como una violación de una ley popular del diseño del lenguaje: "la ley del menor asombro".
Considere la siguiente expresión: 25+1/3. El resultado de evaluar esta expresión no está definido y se genera la condición FIXEDOVERFLOW porque la división FIXED da como resultado un valor de precisión máxima definida por la implementación. [...] Los resultados de las dos evaluaciones se obtienen como se muestra en la Tabla 29.
Si la cadena de entrada comienza con "0" (un cero), se supone que el valor de base es 8 (octal) o 10 (decimal). El valor de base exacto que se elija depende de la implementación. ECMAScript 5 aclara que se debe utilizar 10 (decimal), pero no todos los navegadores lo admiten todavía.