19/01/2011
Categoría/s: CSS.
0 Comentarios
Hay gente que dice que es más peligroso un ignorante que un malo. Es una opinión. Y en el mundillo del desarrollo web "front" tiene bastante sentido. Así, entre nosotros, he de confesar que más de una vez he sido de los primeros.
Pero se supone que el asunto a tratar es el reseteo de todas o una buena parte de los atributos de los elementos de XHTML mediante unas cuantas reglas de CSS, e incluso un fichero, como parte de un framework más o menos extendido o particular. Personalmente, la mayoría de las veces he optado por algo muy básico y cuando hacía falta (lo típico del padding:0 y margin:0 y poco más). Lo de usar un fichero que te obligaba a definir todos y cada unos de los atributos de elementos de un sitio web me parece excesivo. Cuestión de opiniones y experiencia.
El caso es que la mejor manera para justificar el uso o no de alguna de las diferentes técnicas de reseteo de CSS es saber sus consecuencias - y porqué no, su origen - tal vez sea una buena idea dar un vistazo a los siguientes artículos:
22/12/2010
Categoría/s: Diseño de interacción.
0 Comentarios
You know how long it takes to do simple? About ten times longer than fast and dirty.
Paul Giambarba
En mis labores de diseñador de interacción "de todo a cien" ™ de aplicaciones para móviles se presenta una tarea sencilla. Una avertencia para avisar que al pulsar un botón en el iPhone, se va a llamar por teléfono. El literal del botón es bastante explícito: es un número de teléfono. Pero no todos los sistemas operativos para móviles se comportan igual. En Android, por ejemplo, después de pulsar el botón, aparece una pantalla característica de la interfaz de Android para llamar por teléfono. Y el botón de llamar en color verde es el que realmente llama.
Personalmente me gusta más la opción de Android, prefiero dar un paso más y evitar en lo posible llamadas accidentales. Es una opinión tan mala como cualquier otra.
Teniendo claro más o menos el literal de la advertencia, viene un detalle que me hade dudar bastante: la aparición de los botones para cancelar o realizar la llamada. ¿En qué orden los coloco? es una de las preguntas que surgen. Toca un rato de buscador. Y me encuentro con que detrás de algo que en apariencia era un detalle menor, hay mucho más de lo que parece.
Por ejemplo, en las interfaces de Windows y en Android, el botón "Aceptar" aparece en primer lugar y después el de "Cancelar". ¿Los argumentos? Lectura "occidental" de izquierda a derecha, el botón más importante se encuentra en primer lugar. Es el que generalmente se va a usar.
Sin embargo en las interfaces de Mac e iOS es al revés. Primero aparece la acción secundaria - Cancelar - y luego la importante "Aceptar". Perdón por el inciso, pero no puedo evitar recordar la imagen que aparece en una presentación de Luis Villa con una ventana de Safari en Mac que dice Pulsa OK para Cancelar
. Y los botones "Cancelar" y "OK". Pero dejemos la nota humorística y vayamos a la argumentación: primero te presenta las opciones alternativas y luego terminas con la opción más importante. Por otro lado, la izquierda se asocia más a volver y la derecha a avanzar.
Al final la decisión del orden de los botones es clara. Primero el botón "Cancelar" y luego el botón "Aceptar", ya que estamos en iOS. Y a última hora me doy cuenta de un detalle que puede ayudar mejor a los usuarios a tomar la decisión adecuada: en vez de un genérico "Aceptar" pongamos un literal mucho más explícito y concreto con la acción a realizar, es decir: "Llamar".
Dejo de lado el modificar el color por defecto de los colores: en principio el color rojo, para la interfaz de iOS se asocia a una acción "destructiva", y no se corresponde ni con llamar ni con Cancelar.
Un par de consejos (son para mí, a vosotros no os hace falta):
- Si no existen motivos para incluir un botón para acciones secundarias, mejor no ponerlo.
- Utilizar literales en los botones que describan qué va a hacer exactamente. Es la misma recomendación tan útil y tan ignorada para los vínculos: usar un texto que tenga sentido al leerse fuera del contexto. Algo que se podría aplicar perfectamente a muchos sistemas operativos actuales.
- Confieso que el botón Cancelar me suele producir bastante confusión por la poca consistencia en su uso, sobre todo en la web. En ocasiones significa "no realizar una acción", pero en otras su comportamiento es el de regresar a la página anterior. En algunas ocasiones me parece prescindible, en otras me hace dudar de su comportamiento. Intento no utilizarlo como usuario e incluirlo como desarrollador, salvo cuando su uso es necesario e intuitivo.
De extra, algunas vínculos relacionados:
* OK and Cancel Buttons What's the Right Order?. Presenta los resultados de una encuesta sobre el orden de dos botones y su separación en una interfaz web.
* OK–Cancel or Cancel–OK? de Jakob Nielsen. Básicamente dice que se use el orden por defecto en la interfaz.
* Primary & Secondary Actions in Web Forms de Luke Wroblewski. Diferentes alternativas para las acciones de "Submit" y "Cancel" argumentado con los resultados de un estudio de eyetracking. Muy buen artículo. Y su libro Web Form Design: Filling in the Blanks, altamente recomendable.
* On love and design de Ale Muñoz. Sí, ya se que no tiene que ver nada con botones "Aceptar" y "Cancelar". Habla sobre diseño. Y formularios. Y si no lo has leído ya, tienes que hacerlo.
Ah, la cita de Paul Giambarba la he recuperado del artículo "10 times longer de Javier Cañada. Y si eres un aficionado de las Polaroids o simplemente al diseño, posiblemente te interese saber que tiene un blog "The Branding of Polaroid en el que cuenta detalles sobre la época en la que trabajaba como diseñador para Polaroids, sin duda la época dorada. Igualito que ahora, que tras abandonar el negocio de la fotografía instantanea hace unos años, y justo cuiando vuelve a ser trending topic (vaya, que está de moda) gracias a The Impossible Project, no se les ocurre otra cosa que vender cámaras de la competencia (Fuji Instax Mini 7), con el nombre de Polaroids 300 y promocionarlas por Lady Gaga y Sting.
Me pregunto cómo he terminado hablando de Lady Gaga cuando quería hablar de botones de formulario...
04/11/2010
Categoría/s: Web Semántica.
0 Comentarios
Me he enterado por el twitter de Dublin Core. Se trata de un pequeño artículo que a su vez hace referencia a un anuncio de Google. Mola.
Empecemos por el artículo: Semantic SEO for Google with GoodRelations and RDFa. Y lo que viene a decir es que usando un buen código con algunos ingredientes semánticos (RDFa), las búsquedas en Google van a ofrecer una información más completa y lo que excitará la líbido SEO de más de uno: un 30% más de CTR.
Y aquí viene el origen: un modelo de metadatos relacionados con el comercio, especialmente electrónico: Good Relations (publicado el 16 de Septiembre de éste año) y que entre otras compañías -dicen que - está siendo usada por BestBuy, Overstock, Yahoo!, O'Reilly, ... y Google.
La historia, dentro de la Web Semántica es la de siempre: intentar generar información en la web que sea comprensible por los los buscadores. Lo bueno es que ahora mismo usando un portal de comercio electrónico (OS Commerce, por ejemplo), puedes usar un pluggin para mostrar la información de los productos no sólo en "formato web-para-personas", sino que además en "formato-web-para buscadores", es decir, RDFa. El resultado, mejor información y más completa.
Recomendación: darle un vistazo a los siguientes vínculos:
02/11/2010
Categoría/s: Diseño de interacción.
0 Comentarios
De acuerdo, se ha hablado mucho y se hablará del concepto de personas en la fase de modelado para describir patrones de comportamiento y objetivos de los usuarios. La técnica ha sido desarrollada por Cooper y puedes encontrar ampliamente desarrollado en el libro "About the face 3" (a Freddy pongo por testigo que algún día acabaré de leer el libro).
Pero seamos sinceros: aunque obviamente es más recomendable leer el libro porque se puede aprender mucho, 600 páginas son muchas páginas para un libro. Pesa mucho y hay que dedicarle mucho tiempo para leerlo: y más un libro de estas características, en el que encuentras motivos para reflexionar en cada página. También hay muchos artículos más breves que se centran en el concepto de personas. Pero si el artículo está expresado con viñetas, resulta más cómodo y divertido, por lo menos para una fase de acercamiento inicial.
Tachán... en How to Understand Your Users with Personas vas a poder encontrar un entretenido y breve comic divulgativo sobre la técnica de personas. Por cierto, no soy el primero en decirlo, pero tal vez, se debería haber traducido personas and scenarios como personajes y escenarios. Damas y caballeros, no es lo mismo.
27/10/2010
Categoría/s: Web móvil.
0 Comentarios
La noticia es de hace algunos días: pero ya sabes que la rápidez en publicar noticias no es uno de mis fuertes.
El caso es que el W3C ha publicado un documento bastante interesante y más que necesario. Lo comentaba hace algunos meses - mil perdones por la autocita- El complicado papel de los proxys-transcodificadores en la web móvil. Y es que el asunto tiene una enorme transcendencia. Por un lado hacen posible que se pueda navegar por la web con teléfonos bastante limitados, pero por otro lado dificultan la labor de los desarrolladores al cambiar datos tan importantes, desde el punto de vista de la programación, como el agente de usuario. Y es que el conocimiento del agente de usuario hace posible conocer las características del dispositivo (tamaño de pantalla, soporte de javascript, lenguaje de marcas soportado, formato de imágenes que admite,...) sea información muy valiosa y que repercute positivamente en los usuarios. Por otro lado, los proxys también intentan faciltar la vida de los usuarios y les posibilita entrar en sitios webs que directamente no podrían.
El debate, los conflictos y la colisión es inevitable. Sobre todo cuando no se juega limpio (¿alguien ha hablado de la seguridad?).
Volviendo al W3C: el documento publicado, en estado de Working Group Note (una especie de "informe técnico") es el siguiente: W3C Guidelines for Web Content Transformation Proxies 1.0.
Para ir abriendo boca, aquí va un pequeño extracto de la introducción:
Content Transformation proxies alter requests sent by user agents to servers and responses returned by servers so that the appearance, structure or control flow of Web applications are modified. Content Transformation proxies are mostly used to convert Web sites designed for desktop computers to a form suitable for mobile devices.
Based on current practice and standards, this document specifies mechanisms with which Content Transformation proxies should make their presence known to other parties, present the outcome of alterations performed on HTTP traffic, and react to indications set by clients or servers to constrain these alterations.
The objective is to reduce undesirable effects on Web applications, especially mobile-ready ones, and to limit the diversity in the modes of operation of Content Transformation proxies, while at the same time allowing proxies to alter content that would otherwise not display successfully on mobile devices.
Important considerations regarding the impact on security are highlighted.
Guidelines for Web Content Transformation Proxies 1.0
Hay que darle un vistacillo.
