GUIdebook

Via Microsiervos he descubierto GUIdebook, un sitio web sobre interfaces gráficos de usuario. Con apartados dedicados a los elementos de los interfacs, iconos, pantallas de inicio,… es un sitio fantástico para los que nos gustan estas cosas. La cronología de interfaces es para no perderla de vista, asi como los enlaces a otros sitios web. Toda la web es un guiño constante a la historia de los GUI, desde las pestañas ¿ a lo POSIX ? hasta la tipografía utilizada.

La tipografía del sitio es la fuente meta que en algún sitio leí que había sido la fuente más famosa de los 90. Recuerdo que la primera vez que vi esta fuente fue en la edición española de la revista Byte y quedé prendado. Para los que no tengamos esta fuente, en Windows XP existe la fuente trebuchet que tiene un cierto parecido.

iconos de everaldo

Everaldo Coelho es el autor de los famosos iconos Crystal que se usan en el escritorio KDE de Linux. El uso de estos iconos es de pago, sin embargo ha liberado un conjunto de iconos como gratuito, o eso entiendo yo en esta imagen:

He pensado en usar algunos de estos iconos en mis programas, pero tengo que llevar cuidado: si el conjunto de iconos no cubre mis necesidades tengo 2 opciones: hacer yo un icono de este estilo, cosa que en mi caso es imposible, o contratar a Everaldo para que me haga los iconos que me falten.

Suelo delimitar muy claro donde uso iconos que no son mios para no caer en ninguno de estos casos. Por ejemplo, quiero usar algunos de estos iconos para reemplazar los mensajes que muestro al usuario, pero nada más. De esta manera doy un toque elegante al programa, pero no me meto en aprietos de usar cosas que no son mias y no he comprado.

Por cierto, creo que algunos de estos iconos se usan en la distribución de pago de xHarbour.com.

colores y trencadís

Via María Jordano – por e-mail -un interesante artículo sobre uso armónico de colores. Asignatura pendiente de más de uno.

El nuevo logo de alanit intenta reproducir uno de los motivos estéticos que más me gusta. Se llama trencadís y es facilmente reconocible en algunas de las obras de Antoni Gaudí. Cuando vi el Park Güell quedé totalmente fascinado y esa fascinación me ha acompañado hasta hoy. Para mi no hay nada que supere al modernismo ni nadie que supere a Gaudí. El otro dia, buscando motivos para una vidriera que quiero hacer encontré en la web ArtTrencadis. Venden artículos de cerámica que parecen auténticas obras de arte. Una muestra:

folders XP con FWH ¿ misión imposible ?

En el build de Julio de 2003, FiveTechSoft anunciaba la siguiente mejora en su librería FWH:

* Enhancement: Windows XP true folders! are ready for FWH/FW++. They are backwards compatible with your existing folders. All you have to do is change «TFolder» into FOLDER32 (or SysTabControl32) into your resources. No source code changes are required!

Como esto era algo que llevaba buscando bastante tiempo para incorporar a mis programas compré la citada actualización de FWH. Al probar el control, me encontré que éste no funcionaba bien. Las pestañas se pintaban bien y el cuerpo del folder hacía el degradado de los folder de XP, pero los controles estáticos hacían la trasparencia sobre el color del diálogo que había detrás en vez de sobre el color del folder. Asi:

Puesto al habla con FiveTechSoft estuve 2 meses esperando una solución al problema. La solución que me dieron era quitar el brush NULL del cuerpo del folder, de manera que se perdía el degradado que hace XP sobre los folder y este queda con el mismo color que la trasparencia. Comentando la linea donde se asigna el brush NULL a los diálogos del folder:

#ifndef __CLIPPER__
// oDlg:SetBrush( TBrush():New( "NULL" ) ) //byhDC
#endif

y después de ajustar los valores de coordenadas en el método Initiate del control

::aDialogs[ n ]:SetSize( ::nWidth()- 8, ::nHeight() - ::nFdHeight - 4 )

el ajuste del diálogo del folder no es total, pues queda una linea en blanco a la izquierda del diálogo que no he conseguido quitar. La cosa queda de esta manera:

O sea folder de XP a medias. Una posible solución sería pintar el dialogo de blanco o de un color de los que XP usa para el degradado, pero esa es una mala solución. Nunca se deben pintar controles con un color fijo, pues estamos yendo contra el principio de uniformidad del interfaz de usuario que debemos respetar. Si pintase el diálogo del folder de color blanco, un usuario de Windows98 o Windows2000 vería las pestañas en gris – o en el color del diálogo – y el cuerpo en blanco, lo cual sería una chapuza monumental.

Puesto de nuevo en contacto con FiveTechSoft sobre la manera de hacer diálogos como este:

la respuesta es que realmente estos diálogos son un tipo especial de diálogos llamados Property Sheet y que son como Wizards que implementa el propio Windows. Lo que no se puede hacer con WindowsXP – según FiveTechSoft – es usar folders de XP dentro de un diálogo donde haya otros controles fuera del folder además de los botones de Aceptar y Cancelar.

Mi gozo en un pozo.

Postdata. El caso es que a mi me suena haber visto un ejemplo de un diálogo así en un test de Xailer que me envió José Giménez antes del verano, pero con los últimos cambios de xHarbour no me funcionan los ejemplos que tengo de Xailer.

si puedes usar radios quita los combos

En un artículo anterior ya comentaba que estaba restringiendo el uso de comboboxes a los casos en que tuviera una selección de una lista de valores que fueran estáticos. En Colossus estaba haciendo el formulario de selección de listados y puse dos combos: uno para seleccionar la meteria y otro para seleccionar el tipo de entrada. El segundo combo permitía elegir unicamente entre 4 opciones fijas y además había una gran separación entre las opciones del listado y el siguiente grupo de controles que permite
elegir el título y subtítulo del listado.

Como el número de elementos a elegir es pequeño – sólo 4 – y no hay problemas de espacio en el formulario, lo mejor es quitar este combo, con lo que el formulario ha quedado de esta manera:

Mucho mejor.

nueva imagen de alanit

He decidido hacer una apuesta fuerte por alanit. Tengo un nuevo socio tecnológico y un ambicioso plan de desarrollo de actualizaciones de los programas existentes. También tenemos en mente un nuevo programa que vendrá a completar la oferta de software doméstico. Nuestra ingención es hacer software multilingüe e intentar entrar en el mercado americano.

En su momento contaré más de los nuevos proyectos, pero de momento os enseño la nueva imagen de alanit, obra de mi amigo Manolo Boyer Cantó.

fsdi para xharbour

He adaptado mi clase fsdi – full single document interface – para xHarbour. El resultado es este:

Como se puede ver es un programa a 32 bits, que coge perfectamente el tema de mi escritorio gorilla. Para funcionar se necesita un build de FWH posterior a junio de 2003, pues había un error en las versioes anteriores que hacía que funcionase mal la herencia de la clase Dialog.

La clase fsdi para xharbour la puedes descargar aqui – fichero de 512KB con fuentes y ejecutable para los no fivewineros. Es freeware, pero mantengo el copyright sobre ella y agradecería a los posibles usuarios de la clase que me escribieran para darme su opinión sobre la misma.

un bonito calendario

Una cosa que suelo hacer a menudo es visitar webs de empresas que hacen software y fijarme en los diseños de sus programas. Esto me da ideas para mis programas y de vez en cuando capturo alguna imagen para retenerla. Por ejemplo este calendario, no se de dónde lo saqué, pero creo que es de los mejores que he visto.

CalendarCombo.jpg

¿ dónde ponemos los botones ?

dónde adv. interrog. ¿ en qué lugar ? Diccionario del español actual

Dedicado a Jaime Irurzun Graña

Uno de los principales objetos de un interfaz gráfico de usuario son los botones de comando. Suelen tener forma rectangular con una etiqueta descriptiva y al pulsarlos el programa ejecutará una acción determinada. Pero… ¿ dónde los ponemos ?

La ubicación de los botones en una ventana secundaria es algo fundamental, pues normalmente son los elementos más importantes de la misma. Pensemos en cualquier dialogo de un mantenimiento: el botón Aceptar nos permite almacenar la información introducida y el botón Cancelar nos permite descartar la información introducida en el diálogo y salir de allí sin grabar nada.

Uno de los principios del diseño de interfaces dice que una ventana debe leerse como se lee un libro, en las lenguas occidentales esto supone leer la ventana de izquierda a derecha y de arriba abajo. Pensemos lo que debe hacer un usuario en un diálogo de mantenimiento: deberá recorrer el diálogo introduciendo sus datos y una vez finalizada la introducción de datos deberá guardar esta información. Los botones de comandos finalizan el dialogo por lo que parece claro que su ubicación es en la parte baja del diálogo. Además, si nos fijamos en cualquier diálogo de Windows, veremos que cuando los botones aparecen abajo se ajustan a la derecha.

Debemos fijarnos en los detalles. El botón Aceptar siempre va a la izquierda del botón Cancelar, y si hay más botones normalmente se situarán a la derecha del botón Cancelar.

Pero… ¿ qué pasa si necesitamos más botones ? Lo que no debemos hacer nunca es poner dos filas de botones. La solución pasa por ponerlos en vertical a la derecha del diálogo. Algo como esto:

Aquí estamos siguiendo el principio de leer el diálogo de izquierda a derecha y de arriba abajo. Primero elegiremos la materia que deseemos y luego pulsaremos el botón de comando. Si la materia que deseamos está disponible haremos click en Aceptar, y si no la daremos de alta pulsando el botón Nuevo o haremos cualquier otra acción.

Una cosa que no me parece apropiada es situar botones de comando a la derecha de un diálogo o ventana. Entonces ¿ el siguiente formulario está bien diseñado o está mal ?

Pues… mitad y mitad, me explico. La secuencia correcta debería ser interactuar primero con la rejilla de datos y luego con los botones de acción, por lo que estos deberian estar a la derecha. Sin embargo en ventanas que ocupan toda la pantalla – como el Explorador de Windows – estamos acostumbrados a tener las rejillas de datos a la derecha. El caso del Explorador es diferente de una ventana de un mantenimiento pues lo que tiene el Explorador a la izquierda es un árbol que va desplegando el contenido de las ramas a la derecha, y ahí si se respeta la lectura de izquiera a derecha. En el caso que nos ocupa, muchos programas de gestión – creo que el primero de todos fue Microsoft Money – usan interfaces de este tipo, con lo que constituyen un estandar de facto y los usuarios de este tipo de software esperan encontrar el menú de acciones a la izquierda.

Yo unicamente uso botones a la izquierda cuando los agrupo en una barra de botones. Si tengo que poner botones sueltos, como en el diálogo de selección anterior, siempre los pongo a la derecha.

Conclusión:

  • Aceptar y Cancelar abajo a la derecha y en este orden.
  • Si los botones de un diálogo no te caben abajo, ponlos a la derecha, nunca pongas dos filas de botones.
  • Si vas a agrupar los botones en una barra, ponlos a la izquierda.