Curso Applescript: AppleScript e Interfaz de Usuario, por Julifos

En inglés nos encontraremos con las palabrejas interface, UI (User Interface) o GUI (Graphical User Interface). Este concepto es muy importante para Apple y, en general, para todos los usuarios mac. Los applescripter, como usuario de macintosh y desarrolladores (developers), tenemos una responsabilidad gorda total con la Interfaz de nuestra aplicación.

Lo más importante es que nuestro programa funcione. Y, después de eso, que el usuario sepa utilizar nuestro programa. Esto comprende dos sub-ideas: que el usuario sepa cómo hacer funcionar el programa (que sepa para qué sirve cada cosa) y que esté informado en cada momento de lo que se cuece (sí, barras de progreso, soniditos informativos y demás).

Este capitulillo trata sobre las interfaces en AppleScript. Si ha lugar, se explicará el cómo técnico en profundidad (ya hay algún artículo que habla del tema). Aquí sólo se mencionarán las técnicas básicas.

el exterior de nuestro programa

Como puede vd. imaginar, “nuestro programa” es una pila de letras que, al ser ejecutadas, hacen cosas raras en el ordenador. Como el usuario de nuestra aplicación -sea quien sea: mi vieja, el vecino o un señor de Minnesota- no tiene ni puta idea de qué son esas letras extrañas ni le importa, tenemos que adaptarnos a una serie de estándares para que el vecino sepa qué es y cómo de utiliza nuestra aplicación. Este concepto se puede llamar usabilidad.

Por ejemplo, si creamos una aplicación que busca ciertas cosillas entre nuestros mensajes de Entourage o Mail, deberíamos pensar en primer lugar un nombre apropiado para nuestro programa. Algunos se dedican a pensar nombres para futuros programas y luego nunca los escriben, y otros los escriben y luego no los pasan a los colegas, o no piensan nombres adecuados… En fin, hay de todo.

Si mi público objetivo es “mi vieja” (una señora anciana con muchos bisnietos, manchas de tomate en la pechera y gafas de culo-botella), lo mejor sería que llamásemos a nuestro programa “Pínchame, que miro el CORREO, a ver qué hay”).

Si mi público son mis compañeros de la Renault -dos pibas gordas con el pelo recogido y gafas de pasta, que vienen de filología inglesa-, bastaría con un “Consultar correo Entourage” (mucho más simple).

Si mi público es una persona acostumbrada a utilizar un ordenador, prefiero algo más simple: “Extrae-Mail”. Probablemente, esta persona ha encontrado mi programa en un sitio específico para Mail/Entourage y sabe perfectamente lo que significa “Extrae-Mail”.

Y si mi público es alguien desconocido que habla inglés y sabe mucho de computadoras, lo mejor es que lo ponga en inglés: “Mail-Extract”.

Ahora se pregunta vd. ¿y qué pasa si mi programa no es tan específico que pueda ser descrito de manera tan explícita? Pues imagine vd. algo, buen hombre, que se adapte a sus necesidades. Si su programa es un juego que plantea enigmas, póngale “Enigma” o “Rappel” o “David Copperfield” o algo asín. Pero no ande tocando los huevos. Ya sabe vd. a lo que me refiero… ¿O no?

Y lo mismo para el icono de la aplicación (si es que me veo con fuerza para diseñar uno…). Para el ejemplo que hemos puesto, podría estar bien el icono de Entourage mezclado con una lupa (que es el estándar para el concepto “buscar”). Para el ejemplo de los enigmas, habría que emplear una interrogación o cualquier cosa que se nos ocurra que puede representar un enigma y que actualmente NO EXISTE dentro de los estándares. Si, por poner otro ejemplo, tenemos una aplicación que examina el disco duro… Pues hay cienes y cienes de iconitos que representan discos duros. Pero deberíamos escoger uno que sepamos que se va a entender, y no nuestro diseño futurista de disco duro, que no se sabe si es un huevo o una castaña.

¿Por qué hay que ser tan evidente y poco original? Porque sí. Punto. Porque cualquier usuario lo va a entender (es el objetivo fundamental: la comunicación con el usuario, la usabilidad de nuestra aplicación). Tenga vd. en cuenta que los usuarios “usan” muchas cosas en sus equipos. Vamos, que nuestro programa no es la ÚNICA aplicación en su disco, ni el ÚNICO icono de su escritorio. Estamos prestando un servicio al usuario, y debemos ayudarle visual y conceptualmente a organizarse.

¿Esto significa que no puedo utilizar mi icono-último-modelo-superguay? NO. Si el usuario va a comprender lo que ve, se vale.

TODO LO DICHO HASTA AHORA sirve para el resto de las cosas que el usuario ve ANTES de darle al “botón de empezar” en nuestra aplicación: los archivos de ayuda (si los hay), la pantalla principal (si la hay), los botones, colores, gráficos, imágenes que utilizamos, el idioma, las preferencias… Cuanto más ayudemos al usuario, mejor será la interfaz de nuestra aplicación. Utilicemos la lógica.

No se deje vd. confundir por mi verborrea. Lo que digo no es dogma. Hay unos señores muy listos en Apple que ya lo han inventado todo. Actualmente, se puede ver aquí: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/

En estos documentos se dice que estos son los modus operandi para aplicaciones Carbon y Cocoa (esto incluye aplicaciones AppleScript), y parece que deja manga ancha a otro tipo de aplicaciones, como las hechas en Java (que, según mi parecer, se comen toda la memoria del sistema que pueden, son horrorosamente feisísimas y etc., etc.). En fin, lo ideal es que sigamos las instrucciones del Señor Manzanas.

De hecho, si le echamos un ojo a Interface Builder (el constructor de interfaces que utilizamos en AppleScript Studio), veremos que los botones y demás elementos son estándar, y que también se marcan las distancias que ha de haber entre unos elementos y otros con unas guías un poco plastas que hay. En cuanto al uso gráfico de elementos de interfaz (botones y demás), también habremos de aplicar la lógica. Si, por ejemplo, nuestra aplicación envía emails, pondremos los elementos en este orden (u otro parecido): mensaje de, mensaje para, asunto, cuerpo del mensaje (y así sucesivamente). Por lógica. Echemos un ojo a cualquier cliente de email y veremos que la estructura suele ser esa.

También procuraremos (si es de aplicación) que si hay varios campos de texto, al pulsar tabulador se pueda pasar de uno a otro, definir atajos de teclado para nuestros menús, utilizar la tipografía estándar del sistema, los colores del sistema (los definidos en la pestañita “Developer” del selector de color de sistema), etc. Lógica, lógica, lógica…

Aparte de que nos quede mono, la utilidad mayor del uso estándar de elementos gráficos radica en que el usuario entenderá qué es lo que tiene que hacer, y para qué sirve cada cosa. Lo cual significa que el usuario no nos mandará cientos de email preguntando para qué sirve no-sé-qué que hemos puesto en nuestra pantalla principal. Créame, eso es muy útil si nuestra aplicación la van a utilizar cientos o miles de personas.

El interior de nuestro programa

Básicamente, si hemos diseñado un programa de manera inteligente, será inteligente tanto externa como internamente. En la medida de nuestras posibilidades, hemos de informar al usuario en todo momento sobre lo que se está cociendo.

El ejemplo más evidente son las pantallas de inicio que estamos acostumbrados a ver en muchos programas: “cargando gráficos”, “optimizando rendimiento del menú de fuentes”, “loading preferences…”. ¿Por qué se utilizan estas pantallitas? Porque los susodichos programas tardan un rato en cargar. Antes de enseñarle al usuario la pantalla principal, y que éste pueda tocar algo sin que todavía sea operativo y lo joda todo, tiene que ejecutar una serie de rutinas para que la interfaz sea operativa. Si no hemos cargado las doscientas-y-pico imágenes que se van a mostrar en nuestra pantalla principal (lo cual, dicho sea de paso, sería un craso error), ¿cómo vamos a mostrar la pantalla principal? ¿Sin imágenes? NO. Primero cargamos las imágenes, las preferencias y lo que haga falta, y después dejamos al usuario que le dé la gana, una vez que tengamos todo amarrado.

Otro caso típico son las barras de progreso. El usuario define unos parámetros utilizando campos de texto, botoncitos, etc. Y luego pincha el botón “OK” o “Empezar” o “Aplicar” o como-quiera-que-se-llame, y nosotros hacemos algo. Si nuestro programa es Photoshop y tenemos que aplicar un filtro sobre una imagen de 500MB, o tenemos que renombrar 5472 documentos que hay en una carpeta del Finder, se prevé que tardará un ratillo.

Después del primer segundo, el usuario sentirá un sudor frío subiendo por su espalda. Durante el segundo, se hincharán las venas de su frente. Y durante el tercero, se pondrá de color ámbar, musitará “mierda pograma, no había guardado” y es posible que arranque el enchufe de cuajo. Luego, cuando haya reiniciado, nos pondrá un email muy amable acordándose de nuestra madre.

Para evitarle el sofocón a nuestro usuario, podemos utilizar una barra de progreso con un mensaje informativo: “Procesando archivo 1 de 5472”. Incluso, si odiamos las barras de progreso o estamos escribiendo un programa tan sencillo que no merece la pena gastar cienes de horas haciendo una interface superbonita-de-la-muerte, podemos enseñarle un mensajito al usuario antes de ejecutar la acción-que-lleva-tiempo: “Oiga, voy a procesar 5472 archivos. Espere un poco y no toque nada. Si algo va mal, ya le avisaré.”. Esto es muy simple. Y si no lo hacemos, no tenemos excusa: recibiremos inevitablemente el email sobre nuestra madre.

Algo que nos evitará trabajo futuro y que mantendrá al usuario lejos del enchufe, también, es la previsión de errores en nuestro programa. Deberíamos prever posibles errores en nuestro programa y: a) instruir a nuestro usuario para que no vuelva a hacerlo, o le mataremos; b) instruir al usuario para que nos envíe un mensaje con el error concreto; c) informar al usuario de que nuestro programa y él son incompatibles.

Si nuestro programa está hecho para ser ejecutado en OS 10.3.x, deberíamos hacer saber al usuario que su OS 10.2.5 no sirve para nuestro programa. Lo advertiremos en la documentación del programa y, si es posible, durante la ejecución del mismo. Si nuestro programa sólo procesa documentos .txt y nuestro usuario intenta procesar un directorio (una carpeta), le diremos que no lo haga (o le restringiremos de alguna manera para que sólo pueda procesar archivos .txt, o le informaremos en un cuadrito de texto). Si nuestro programa sólo sirve para procesar archivos TIF que estén en escala de grises y el usuario lo intenta con uno de color, le avisaremos. Si cabe la posibilidad de que procesando un archivo llamado “káspita.jpg” se produzca algún error porque tiene un carácter que consideramos ilegal (la “á”), haremos lo posible por informarle de que ha intentado procesar un archivo con un carácter ilegal. Y así sucesivamente.

Esto evitará que recibamos emails sobre nuestra madre, y hará que recibamos en cambio mensajes tipo “oiga vd., que he recibido un error que decía bla, bla, bla”. De esta manera: a) El usuario se dará cuenta de su error y ni siquiera nos enviará el mensaje; b) Si la culpa es nuestra, sabremos en qué parte del código está nuestro problema, y podremos darle solución por la vía rápida.

Un ejemplo:

repeat

 set laDistancia to text returned of (display dialog “Introduzca la distancia que hay hasta el Burger King más cercano (en kilómetros)…” default answer “3”)

 –> observar si hay error

 try

  set laDistancia to laDistancia as number

  exit repeat

 end try

end repeat

Si el texto introducido en nuestro diálogo es un número, saldremos del bucle repeat y haremos algo con ese número. Si no (y no se puede vd. hacer una idea de la cantidad de cosas absurdas que el usuario puede introducir por error en un campo de texto), se volverá a repetir la pregunta, hasta que el usuario introduzca un número válido.

Podríamos afinar aún más, comprobando si el usuario ha introducido “” (o sea, nada), lo cual no nos valdría, aunque al pasarlo a número nos devolviese un “0” y fuese válido. O si ha introducido un número decimal, o negativo, o superior a 5000, etc.

Esta es una de las partes que más trabajo conlleva, y también la que más trabajo ahorra para el futuro. ¿Se imagina vd. el email hablando sobre su madre, y diciendo que “tu pograma no funciosna, kapullo”? Sería mucho mejor recibir uno diciendo “bla, bla, bla tu madre. El programa me dice por favor, no deque introducir números decimales, y eso qué-esss”. Así, podremos explicar al usuario “oiga, no ponga vd. nada distinto de los números 0123456789 o sus combinaciones en la cajita de texto”, o “uy, perdón, tengo que adaptar mi programa para que pueda vd. utilizar sus números decimales”. O lo que sea. Pero ya sabremos dónde está el error.

Por favor, no confundir “previsión de errores” con “provisión de errores”; la diferencia está en que la “previsión” permite evitarlos y la “provisión” se ocupa de acumularlos.

Por último: tampoco hace falta avasallar al usuario con mensajes, pitidos, iconitos y fuegos artificiales. Basta con que sepa qué está haciendo nuestro programa en cada momento, sin interrumpir otras actividades que esté realizando. Por tanto, debe evitarse en la medida de lo posible soniditos distintos de un sencillo beep, mostrar diálogos de confirmación a cada paso, traer nuestra aplicación al frente y otras técnicas tocahuevos habituales en ciertos sistemas operativos que no son Mac OS X.

Herramientas para crear interfaces

AppleScript en sí mismo posee unas pocas habilidades interfacísticas que son suficientes para programas sencillos. Están todas en las Adiciones Estándar: display dialog, beep, choose file, etc. Échenle un ojo.

El resto de elementos estándar que se puede encontrar en cualquier aplicación (desplegables, texto con formato, casillas de verificación, barras de progreso, imágenes y vídeo, etc.) están todos en AppleScript Studio, que es un ente compuesto por Xcode (también llamado Project Builder en ediciones anteriores del sistema operativo), Interface Builder y nuestro código applescript. Todas estas herramientas vienen en los CD/DVD de instalación de sistema, en la parte Developer para desarrolladores, que se instala opcionalmente en la carpeta “Developer” del disco duro. Si me da tiempo, algún día escribiré una pequeña introducción a AppleScript Studio para vdes. Si no, échenle un ojo al sitio de Apple y busquen información. No es muy difícil, porque todo el mundo lo usa…

Y luego, hay un batiburrillo de posibilidades (de mano de otros desarrolladores), que simplemente voy a enumerar:

24u Appearance osax, Extra Suites, iHook, progressbarmetal, FaceSpan, Pashua… Y probablemente haya más, pero eso depende del año en que estemos 😉

Cada herramienta funciona de manera distinta. Appearance osax es una adición de scripts. FaceSpan es similar a AppleScript Studio, y cuenta con mucha tradición en el mundo AppleScript, aparte de que está pensado única y exclusivamente para applescripter, que siempre es una ventaja… Extra Suites es una aplicación background. Y etc. Cada cosa con sus ventajas e inconvenientes. Sopésenlo y escojan.

Antes de terminar, me declaro culpable de ignorar todo lo que predico sobre las interfaces. Odio las interfaces (cuando soy yo el que tiene que crearlas, claro). Pero sí que es verdad que los usuarios las adoran (igual que yo, como usuario de otras aplicaciones). ¡Ale!

Los restantes artículos sobe AppleScript se pueden encontrar en la categoría de Tutorial

0 0 votos
Article Rating
Subscribe
Notify of
1 Comment
Oldest
Newest Most Voted
Opiniones Inline
Ver todos los comentarios
Anónimo
Anónimo
16 years ago

Como hago para activar en el entourage que cada 10 minutos por el mismo reciba los mails.
MI SEGUNDA DUDA ES una font se instalo casi que como predeterminada en mi mac g5 y en algunas ocaciones la usa como predeterminada y me aparece en mails y paginas web algunas letras cambian con ese font y me es imposible leer si alguien me puede ayudar, me urge esto no he sabido como hacerle.

1
0
Me encantaría saber tu opinión, por favor, deja un comentariox
()
x