Cómo diseñar software bueno en Haiku. (1)

https://www.haiku-os.org/docs/HIG/index.xml


Haiku es un sistema operativo conocido por su velocidad y por ser fácil de usar para cualquier persona. Esto se debe en parte a que los buenos programadores intentan diseñar sus aplicaciones para algo más que ellos mismos. Vamos a examinar cómo puede hacer que su programa sea más atractivo. La razón es simple: más fácil de usar significa que más personas usan su programa. Escribir un buen software puede ser difícil, pero vale la pena el tiempo y el esfuerzo.

¿Quién lo va a usar?

Probablemente ya sepa qué tipo de programa va a escribir. Si no, guarde este libro y piense un poco primero. Sin una idea clara de lo que quieres, es difícil hacer algo al respecto. Una vez que sepa qué tipo general de programa le gustaría crear, también necesita averiguar para quién está destinado el programa. Esto puede ser algo tan general como 'usuarios de escritorio' hasta algo tan específico como 'Desarrolladores web de Haiku'. Cuando sabe quiénes serán los principales usuarios de su programa, puede hacer ciertas suposiciones sobre lo que saben sus usuarios. No necesariamente puede esperar que un músico entienda cómo usar de manera efectiva un programa de modelado 3D tan avanzado como, digamos, 3D Studio Max, pero puede esperar que tenga habilidades que se presten a usar un programa para escribir música.

Dependiendo de qué tan preocupado esté por los detalles, es posible que desee crear un perfil de usuario, una idea ficticia de un usuario de ejemplo. Esto puede consistir en solo una o dos oraciones o puede ser de varios párrafos. Un perfil de usuario breve contiene el nombre de la persona, la ocupación, el nivel de experiencia y el tipo de cosas que desea poder hacer con su computadora. Una cosa de la que debes estar seguro es hacer que el perfil de usuario sea creíble, como una persona que podrías conocer. De hecho, cuando diseñe su aplicación, puede ser útil si conoce a alguien que se ajuste a la audiencia objetivo. No desea diseñar su aplicación para esa persona específicamente, sino para alguien como ellos.


¿Qué estará haciendo el usuario?

La mayoría de las personas usarán su software para hacer el trabajo, a menos, por supuesto, que esté escribiendo el próximo juego exitoso y, a pesar de las experiencias que pueda haber tenido, que pueden hacerle dudar, los usuarios son bastante inteligentes. El dicho de que nadie lee manuales es mayormente cierto: las personas generalmente tienen mejores cosas que hacer que leer manuales de software, excepto cuando están en problemas o como lectura en el baño. Trate de tener en cuenta cuán ocupada está la mayoría de las personas y cuán valioso es su tiempo para ellas cuando diseñe su programa.

Para facilitar el trabajo con su programa, debe priorizar qué tipos de trabajo realizarán en orden de frecuencia. Cree una lista de tareas que el usuario realizará y colóquelas en una de las 3 categorías: comunes, poco comunes y raras. Las tareas comunes, como era de esperar, son aquellas cosas que el usuario hace todo el tiempo. En un procesador de textos, esto incluiría escribir texto, cambiar el tamaño y el estilo de las fuentes y ajustar los márgenes. Las tareas poco comunes son aquellas que el usuario hace solo de vez en cuando. Según el usuario, esto podría ser algo como imprimir etiquetas, agregar color a una tabla o contar las palabras en el documento. Las tareas raras son aquellas que se realizan de vez en cuando. Muchas veces, estas tareas son las que el usuario probablemente no perdería si no fuera posible realizarlas con su programa. Este también sería el tipo de cosas que solo el 20 por ciento de sus usuarios o menos terminarían usando. Si decide incluir funciones para manejar tareas raras, piense detenidamente sobre la importancia de cada tarea en el gran esquema de las cosas antes de decidir con alguna finalidad.

Parafraseando a Einstein, debe hacer que su software sea lo más simple posible pero no más simple. La complejidad debe mantenerse al mínimo. Una forma importante de hacerlo es evitando las funciones que se usan solo en instancias remotas: las tareas en el grupo Raro. Diseñe su aplicación para satisfacer las necesidades del 80 por ciento de su público objetivo. Las características agregan complejidad y la complejidad agrega dificultad.

¿Cómo harán su trabajo los usuarios?

Una vez que sepa quiénes son sus usuarios y qué harán, deberá averiguar cómo se hará en un sentido general. Sin embargo, esto no incluye cómo se verá realmente su programa. En una aplicación de finanzas personales, una de las principales tareas del usuario será ingresar transacciones. El usuario deberá teclear los datos de cada transacción o descargarlos de su banco a través de Internet. Necesita conocer este tipo de información para cada tarea que el usuario tendrá que realizar, común o no.

La implementación real se determina en último lugar, por lo que no se ha discutido hasta ahora. Aquí es donde se determina el uso general de la aplicación. Por ejemplo, el usuario tendrá un formulario para ingresar transacciones en una cuenta. El formulario debe tener campos de texto para cada uno de los diferentes tipos de datos, como el beneficiario, el monto y el número de cheque. En algún lugar cercano, el usuario podrá ver una lista de todas las transacciones en la cuenta corriente. Debido a que aquí es donde tiene lugar la construcción real del aspecto del programa, es crucial en este punto del desarrollo saber y comprender qué hace que el software sea realmente fácil de usar, por lo que esto es lo que examinaremos a continuación. Tenga en cuenta que las tecnologías que se utilizarán para crear realmente el programa ni siquiera se han mencionado todavía. Para su audiencia, la tecnología es simplemente el medio para un fin, una herramienta, y no el objetivo en sí mismo.



Resumen

La planificación cuidadosa es la clave para escribir un software excelente, independientemente de la etapa de desarrollo en la que se encuentre un proyecto. Para ser fácil, un buen software solo tiene lo que realmente se necesita. También ayuda al usuario a hacer su trabajo siempre que sea posible. Solo al comprender a fondo qué es el trabajo, cómo se debe hacer y quién lo está haciendo, un programa puede brindar la mejor experiencia posible.

Cualidades de un buen software

Cuando se trata de software, la prueba está en el uso. Si una pieza de software requiere mucho tiempo para aprender, los usuarios solo invertirán el tiempo en aprenderlo si (a) no tienen otra opción más que usar ese software en particular y (b) la importancia de la necesidad que cubre el software es mucho. mayor que la importancia del tiempo del usuario. En resumen, los usuarios aprenderán solo lo que deben para hacer su trabajo e incluso entonces solo cuando se vean obligados a hacerlo.

Un buen software se enfoca en las necesidades reales del usuario

En el Capítulo 1, se mencionó que su programa debe satisfacer las necesidades del 80 por ciento de su público objetivo. Es imposible satisfacer las necesidades de todos los usuarios en el mismo software y aún así conservar cierta apariencia de ser fácil de usar. A veces, los usuarios ni siquiera saben que necesitan o no necesitan una función y depende del diseñador y el desarrollador averiguar qué se necesita. La mayoría de las veces, es mejor tener una pequeña colección de herramientas más especializadas que una que lo haga todo.

Un buen software utiliza lenguaje cotidiano

Los trabajos en la industria de la tecnología de la información son casi siempre puestos profesionales. Un aspecto que hace de TI una profesión es que tiene su propio cuerpo de conocimientos y terminología que lo acompaña. La mayoría de la gente tiene sólo un vocabulario rudimentario 'computerese'. Lo que miran cuando usan una computadora se llama monitor o simplemente 'la pantalla'; la pequeña flecha en la pantalla se llama cursor, y la cosa con la que escriben se llama teclado. Pocos usuarios saben (o les importa) qué es un 'formato de archivo' y menos aún saben qué podría ser un 'sector no válido' en un disquete.

Los buenos programas usan un lenguaje apropiado para la audiencia. El problema es que una gran cantidad de software destinado al usuario general de escritorio se lee como Yiddish para Joe User. En tales casos, se debe usar un lenguaje común y cotidiano tanto como sea posible. Para el software de administración de archivos, los 'volúmenes' son realmente discos; aunque el término no es del todo exacto, una persona normal piensa que un disco es un contenedor de almacenamiento y que ese volumen es lo que tienes demasiado alto en las fiestas realmente buenas. Las imágenes son 'imágenes'. Una persona no 'mata' una aplicación que se ha 'colgado', sino que 'obliga a cerrar un programa congelado'. Detalles como este pueden parecer menores, pero muchas pequeñas mejoras en la facilidad de uso de un programa pueden tener un efecto general profundo. Por supuesto, si su público objetivo son profesionales de TI, este tipo de términos son perfectamente aceptables. Asegúrese de coincidir con el lenguaje cotidiano de su audiencia y, en caso de duda, utilice un lenguaje menos técnico.

Un buen software no expone su implementación

Un buen software funciona de cierta manera porque es la mejor manera de hacerlo o casi, no porque el código se escribió de cierta manera o porque fue dictado por una API subyacente. Un ejemplo de esto sería si un programa de composición musical tiene un tamaño máximo de canción fácil de alcanzar porque el mono de código que lo escribió usó una variable de 16 bits en lugar de una de 32 bits. Si bien a veces hay limitaciones que no se pueden superar, el código real escrito y la arquitectura utilizada cuando se escribió deben tener el menor efecto posible en lo que el usuario ve y trabaja cuando usa su software.

Un buen software utiliza los controles gráficos correctamente

Los controles de GUI estaban destinados a usarse de ciertas maneras, y cuando un programa no los usa de esa manera en particular, es confuso para el usuario y posiblemente peligroso para los datos del usuario. Las casillas de verificación, por ejemplo, se usan comúnmente en listas donde se puede activar o desactivar un valor. Sin embargo, algunos programas los usan para elegir una opción en una lista, aunque los botones de opción están destinados a esta tarea. Los cuadros de texto no deben usarse para etiquetar otros controles. Esto puede parecer de sentido común para la mayoría, pero tenga la seguridad de que hay muchos programas que no hacen algo tan simple como esto. En resumen, use los controles estándar de la forma en que fueron diseñados.

Un buen software tiene un diseño natural para sus controles

Algunas tareas tienen un flujo de trabajo lógico y natural, y los buenos programas están diseñados de manera que aprovechan este flujo de trabajo. Al ingresar una dirección en los Estados Unidos, el orden natural es Nombre, Calle y Número, Ciudad, Estado y Código Postal. Seguir cualquier otro orden frustraría al usuario y también conduciría a más errores al ingresar datos. Esto también se aplica al orden de navegación de pestañas de los controles en una ventana. En términos generales, este orden debe ser de izquierda a derecha, de arriba a abajo o en sentido contrario a las agujas del reloj, según cómo se coloquen los controles y las expectativas asociadas con el trabajo a realizar.

Un buen software da muchos comentarios

Imagine por un momento que acaba de comenzar a convertir un archivo de película a otro formato. Presionas el botón marcado como 'Ir' y esperas. Entonces esperas un poco más. Vas al baño, preparas una nueva taza de café, sacas el correo del buzón, confirmas que los salmonetes todavía están pasados ​​de moda y vuelves a esperar un poco más. Está seguro de haber hecho clic en el botón, pero parece que no sucede nada. ¿Algo salió mal? Solo después de husmear un poco con un administrador de archivos, descubre que todo está bien. No sabías lo que estaba pasando porque el programa no te decía lo que estaba haciendo.

Un buen software mantiene abiertas las líneas de comunicación. Una buena retroalimentación solo significa asegurarse de que el usuario sepa qué está haciendo su programa en un momento dado, especialmente si el programa está ocupado haciendo algo que lo hace esperar. Los programas de grabación de CD y DVD le dicen al usuario cuánto queda antes de terminar de hacer un CD o DVD. Los programas de gestión de archivos indican cuántos archivos quedan por copiar o mover. Los navegadores web animan un pequeño ícono mientras descargan una página web. Los usuarios tienen una tendencia natural a pensar que si nada parece estar pasando, probablemente el programa esté congelado. Asegurarse de que el usuario sepa que su programa está trabajando duro lo tranquiliza.

Un buen software hace que los errores sean difíciles

Se ha dicho que nada puede hacerse infalible porque los tontos son muy ingeniosos. Aun así, dificulta que el usuario cometa un error. Si, por ejemplo, el usuario necesita ingresar algún texto y ciertos caracteres no están permitidos, deshabilite esos caracteres para el cuadro de texto en el que debe ingresarse en lugar de molestar al usuario con un cuadro de mensaje. Si por alguna razón no se debe cambiar el tamaño de una ventana horizontalmente, no permita que el usuario lo haga. ¿Su programa requiere una selección de una lista antes de que el usuario haga clic en Aceptar? Dígaselo al usuario, amablemente, por supuesto, y luego deshabilita el botón Aceptar hasta que se realice una selección. Una solución aún mejor sería seleccionar una buena opción predeterminada para el usuario y darle la opción de cambiarla. Cree restricciones en su aplicación que eviten errores. Esta sería la razón por la que los disquetes de 3,5" tienen una muesca en un lado: se puede insertar en una unidad de una sola manera. Las restricciones también son buenas para los desarrolladores perezosos porque su software falla menos y no necesitan escribir tanto. código de manejo de errores.


Las buenas aplicaciones manejan los errores con gracia

Incluso si dificulta que un usuario cometa un error, espere que su programa tenga que lidiar con los errores. Es posible que un programa maneje los errores de una manera que no deje al usuario preguntándose qué sucedió. Cuando se escribe código, es necesario anticipar y manejar errores de todo tipo, como falta de memoria, falta de espacio en disco, errores de permisos, archivos dañados y pérdida de conectividad de red. Como establece la Ley de Murphy, si algo puede salir mal en una situación dada, probablemente saldrá mal. Espere lo mejor pero prepárese para lo peor: sin bordear el ridículo, maneje cada error que pueda ocurrir. Si lo hace, mejora en gran medida la percepción de su software por parte del mundo exterior. Los accidentes son inaceptables en todos los casos. Período. Los mensajes de error, por ejemplo, deben describir lo que sucedió según el nivel de experiencia del usuario y sugerir qué puede hacer el usuario para remediar la situación. En el peor de los casos, el programa debe proporcionar una manera fácil para que el usuario le envíe información técnica sobre el problema por correo electrónico o por algún otro medio. En todo caso, se preservarán los datos del usuario.

Una forma en que puede ver qué tan bien su programa maneja los errores es tratar de romperlo deliberadamente de todas las formas posibles. Introduzca el texto completo de la receta de quiche de su tía May en un cuadro de texto a la vez. Intente abrir archivos, no tiene nada que ver. Tome un documento válido, haga una copia de seguridad, ábralo en DiskProbe, ingrese tantos datos basura como desee y luego intente abrirlo. Interrumpa su conexión a Internet mientras está en medio de una actualización. Trate de usar archivos con nombres de archivo realmente raros. ¡Sé creativo y ridículo y, sobre todo, diviértete rompiendo cosas!

El buen software es indulgente

Las computadoras son excelentes herramientas para las personas porque son buenas en muchas cosas que las personas no son. Desde una perspectiva que se enfoca en la tecnología, los humanos son imprecisos, ilógicos, desorganizados y cometen errores con frecuencia. Sin embargo, son excelentes para formar hábitos y combinar patrones, dos cosas que las computadoras tienen dificultades para hacer. Haga que los comandos se puedan deshacer siempre que sea posible y cuando no sea posible, asegúrese de informar al usuario de que ese es el caso. Aproveche las fortalezas de una computadora para compensar las debilidades inherentes de una persona.

Resumen

Un buen software requiere mucho trabajo para producir. No es para el estereotipo de "programador perezoso", a menos que sepa dónde es aceptable ser perezoso. Al crear algo de valor para los clientes, un buen software crea una imagen positiva para una empresa y clientes leales que harán su propia publicidad por usted. La mejor publicidad la hacen sus clientes a sus amigos, familiares y compañeros de trabajo.

Hora de Libertad

Post a Comment

Previous Post Next Post