En el diseño de interfaz de usuario y diseño de software , [1] el principio de mínimo asombro ( POLA ), también conocido como principio de 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 lo haga. comportarse, y por tanto no asombrar ni sorprender a los usuarios. 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 con computadoras desde al menos la década de 1970. Aunque el principio se formalizó por primera vez en el campo de la tecnología informática, se puede aplicar ampliamente en otros campos. Por ejemplo, al escribir , una referencia cruzada a otra parte del trabajo o un hipervínculo debe redactarse de manera que indique con precisión al lector qué esperar.
Una de las primeras referencias a la "Ley del menor asombro" apareció en el Boletín PL/I de 1967 (PL/I es un lenguaje de programación lanzado por IBM en 1966). [5] A finales de la década de 1960, PL/I se había hecho famoso 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 + 25producen un error fatal y el resultado 5.33333333333 después suprimiendo el error, en lugar del 25.33333333333 esperado. [8]
La ley apareció redactada íntegramente en 1972:
Para aquellas partes del sistema que no pueden ajustarse a las peculiaridades del usuario, los diseñadores de un lenguaje de programación de sistemas deben obedecer la "Ley del menor asombro". En resumen, esta ley establece que cada construcción del sistema debe comportarse exactamente como sugiere su sintaxis. Siempre que sea posible, se deben seguir convenciones ampliamente aceptadas y las excepciones a las reglas del lenguaje previamente establecidas deben ser mínimas. [9]
Una formulación de libro de texto 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 pretende aprovechar el conocimiento existente de los usuarios para minimizar la curva de aprendizaje , por ejemplo, diseñando interfaces que tomen prestado en gran medida de "programas funcionalmente similares o análogos con los que sus usuarios probablemente 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 interruptores , [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 debe ser el que menos sorprenda al usuario ; en particular, un programador debería intentar pensar en el comportamiento que menos sorprenderá a alguien que utilice el programa, en lugar de aquel comportamiento que es natural al 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. Los 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 acceso directo de ayuda habituales. Es probable que el software que utiliza este acceso directo para otra función cause asombro si no aparece ayuda. [dieciséis]F1 ⌘ Command⇧ Shift/
La biblioteca estándar de un lenguaje de programación generalmente proporciona una función similar al pseudocódigo , que crea un número entero legible por máquina a partir de una cadena de dígitos legibles por humanos . La base convencionalmente tiene por defecto 10, lo que significa que la cadena se interpreta como decimal (base 10). Esta función generalmente admite otras bases, como binaria (base 2) y octal (base 8), pero solo cuando se especifican explícitamente. A diferencia de esta convención, JavaScript originalmente adoptó de forma predeterminada la base 8 para las cadenas que comienzan con "0", lo que provocó confusión en 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 para lograr una experiencia de usuario nada sorprendente.
¿Podría haber un alto factor de asombro asociado con la nueva característica? Si el usuario accidentalmente aplica mal una característica y causa 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.
Como me comentó una vez un amigo mío (esto debe haber sido a finales de la década de 1960), independientemente de lo que se pueda decir al respecto, hay una cosa que PL/I definitivamente no es, y es "el lenguaje que menos asombra".
PL/I es el principal mal ejemplo en este caso; está plagado de construcciones que no hacen lo que piensa el programador, como se ejemplifica con la división FIJA.
desafortunadamente, la expresión '25 + 1/3' produce 5,33333333333333
Para que el programador que no es PL/I 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 provocar úlceras en los programadores. ¿Qué otro lenguaje produciría un error fatal al evaluar la expresión (25 + 1/3)? (Igual de malo, si suprime la verificación de errores, el resultado de evaluar la expresión es 5.3333...)
PL/I es famoso 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 se fuerza a 25 a tener la misma precisión, ¡perdiéndose 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 máxima precisión definida por la implementación. [...] Los resultados de las dos evaluaciones se alcanzan como se muestra en la Tabla 29.
si la cadena de entrada comienza con "0" (un cero), se supone que la base es 8 (octal) o 10 (decimal). La base exacta que se elige depende de la implementación. ECMAScript 5 aclara que se debe utilizar 10 (decimal), pero no todos los navegadores lo admiten todavía.