Programación java

Lamentablemente, la mayoría de la veces no ocurre así. Muchas veces los webmasters destinan una innecesaria mayor porción de lugar a la navegabilidad y a veces también a la publicidad. Por supuesto que la navegacion en un sitio es necesaria, pero no es un fin como el contenido. Como dice Jakob Nielsen, ?La navegabilidad es un mal indispensable y no es un fin en si, por lo que hay que atenuar sus efectos.? Y por otro lado, una web requiere subsistir, lo que hace que la publicidad tambien sea necesaria en muchos casos. Pero ¿realmente hace falta ubicar banners horizontales, skycrapers y mini sites que se expanden, todo en la misma pagina como hacen muchos sitios? Como regla comun segun Jakob Nielsen, al contenido se le deberia dar por lo menos el 50% del lugar de la pagina y como un ideal, el 80%. La navegacion por su fraccion deberia restringirse a un 20% como maximo, a excepcion de las paginas de origen y paginas de navegacion como el mapa del sitio. Y en cuanto a la publicidad, mirandolo del lado de la usabilidad deberia desaparecer. Si realmente requiere sustentarse con ella, deberia analizar incluirla en la en la articula de navegacion en manera de links, botones y demas. Reduciendo asi el lugar de navegacion. En la realidad, realizar esto con la publicidad no es del todo probable para la mayoria, por lo que a la publicidad se le deberia conceder un chico porcentaje que ronde el 5%, y que jamás sobrepase el 10%. Un buen ejemplo para colocar como modelo, que generalmente cumple con esto, son las paginas en las que se exponen articulos. Se puede ver un ejemplo especifico, de una pagina de e-masters que tome para analizar. Y por ultimo, poseemos los lugares en blanco. En muchas ocasiones me encuentro que la gente estima los lugares en blanco en un diseño, inutiles. Esto, es incorrecto. Los lugares en blanco son una mayor ayuda para los usuarios para comprender la distribucion de objetos en una pagina. Por otro lado, si se tiene la alternativa de hacer una separacion con lugares en blanco o con lineas gruesas, es mejor hacerlos con la primera alternativa ya que se descarga mas rapidamente. Hay dos ejercicios que pueden ser mucha ayuda a la hora de analizar estos aspectos. Por un lado puede beber una imagen de su pantalla y contar la proporcion de pixeles utilizados para cada cosa en la pagina en cuestion, para poder ajustar esa proporcion a las medidas mencionadas. Y por otro lado puede descartar uno por uno todos los objetos de su pagina web, si el diseño Seguid funcionando tan bien como antes sin determinado elemento, termine con el. Jakob Nielsen predice esperanzado que en el futuro los navegadores realizaran ?un despliegue más inteligente de las páginas? bebiendo en cuenta las características del monitor de cada usuario (tamaño, resolución, etc.).

Distintos disciplinas tienden a aclarar el concepto de Usabilidad en maneras que se ajustan a sus propios propositos, y por tanto suelen depender de un contexto particular. Por otro lado, la facilidad de uso es solo una fracción de la ecuacion, y por esa razon es que prefiero la definicion enfocada a la eficiencia que da ISO: Usabilidad es el grado en que un articulo puede ser utilizado por usuarios particulares para lograr objetivos especificas con efectividad, eficiencia y satisfaccion en un contexto de uso especifico. (International Organization for Standardization, ISO 9241-11 1998) Usabilidad, en el contexto del diseño de interfaces puede ser descrita como una evaluación multidimensional del nivel común de satisfacción con que un usuario es capaz de completar un conjunto de tareas específicas. Si una imagen vale más que mil palabras... Para bien o para mal, Flash ha cambiado la rostro de la web. La omnipresencia del plugin ha algun que Flash se convierta en un ámbito viable para el desarrollo de aplicaciones de contenido multimedia. En ese sentido, las experiencias creadas con Flash se benefician de la tecnología, más allá de los gráficos y animaciones vectoriales. Brindarle al usuario la habilidad de interactuar con aplicaciones en el navegador es una de las razones esenciales por las cuales Flash se ha convertido en la dispositivo preferida por diseñadores de interaccion alrededor del mundo. Asimismo, la capacidad de mostrar facilmente distintos segmentos de informacion sin necesidad de cambiar o ?actualizar? la pagina, juega un rol significativo en que cada vez mas aplicaciones que laboran con datos dinamicos sean desarrolladas en Flash. Por otro lado, el soporte de video streaming y su creciente calidad en las ultimas versiones del reproductor de Flash, lo han convertido en el plugin de video mejor distribuido del mercado, siendo rapidamente adoptado frente a opciones propietarias, que asimismo son complicados de ajustar a escenarios particulares. Si Flash es tan bueno, cual es el asunto de Jakob Nielsen? Hacia Octubre del 2000, Jakob Nielsen, reconocido purista de la Usabilidad en la web, escribía en una pieza titulada ?Flash 99% Malo?: La tecnología Flash no promueve la Usabilidad por tres razones: incrementa las probabilidades de malos diseños, rompe con el estilo de interacción importante de la Web, y consume recursos que serían mejor utilizados mejorando el valor intrínseco del sitio. (Jakob Nielsen, Flash 99% Bad) Aunque éste artículo fuese actualizado en Junio del 2002, cuando Macromedia lanzó Flash MX al mercado, introduciendo características que facilitaban la creación de aplicaciones más usables y accesibles (con la venia del Sr. Nielsen), el documento es singularmente representativo del tipo de acusaciones de las que ha sido objeto la tecnología Flash, a lo largo de su existencia. De hecho, algunos extremistas de la Usabilidad llegan a ningunear el rol del diseño visual en la creacion de interfaces amigables, y demandan que los creadores de contenidos eviten a toda costa el uso de cualquier tipo de bases que requieran de plugins, o inclusive imagenes. Los bases varian, pero todos coinciden en que la web fuese creada para publicar texto exclusivamente, negando casi 10 años de historia y evolucion de Internet. Para muestra, un boton: El website de Jakob Nielsen es un vivido ejemplo de las fortalezas y debilidades de usar HTML puro en el diseño de un medio informativo. Por otro lado, es sumamente significativo que tengamos en cuenta que los juicios que los detractores de Flash expresan, estan basados en experiencias de segunda mano. Resulta obvio que profesionales no conocen ni han trabajado con la herramienta, y por ello expresan opiniones acerca de lo que la gente ha hecho con Flash, y no en las capacidades reales del producto. Basado en mi experiencia personal, me siento seguro al decir que Flash provee poderosas dispositivos que, utilizadas correctamente, pueden ser puestas al servicio de la Usabilidad. De la misma manera, Flash no es de manera cierta una solucion universal, y propone desafios como cualquier otra tecnologia. Esta en nuestras manos discernir donde y cuando una aplicacion Flash puede ser la respuesta a nuestras necesidades, y este producto pretende servir de orientacion, investigando algunos de los dificultades encontrados con gran frecuencia, y su impacto en el diseño y desarrollo de aplicaciones Flash. Retos DE LA USABILIDAD EN FLASH 1. Detección del reproductor de Flash De acuerdo a las mas recientes estadisticas publicadas por Macromedia, alrededor del 99% de usuarios de Internet en Europa puede alcanzar a aplicaciones Flash automaticamente, al contar con el plugin ya instalado en sus computadores. Aunque estos numeros se ven muy bien, la version mas reciente (Flash Player 7) representa solo el 92.3% del total de instalaciones, acercandose al final de su ciclo de propagacion con un aumento de casi el 4% desde el ultimo censo hace 3 meses. Tipicamente, cada nueva version del reproductor de Flash tarde entre doce y catorce meses en conquistar la barrera del 90%, que suele ser un indicador significativo de que el terreno es ya ?seguro? para aquellos desarrolladores que quieren implementar aplicaciones que hagan uso de propiedades exclusivas del plugin mas nuevo. Entretanto tanto, multiples versiones mayores y menores del reproductor de Flash coexisten en el universo de usuarios de Internet, tal y como se puede apreciar en el grafico. Esta informacion es indudablemente valiosa, pero no mas que vuestro conocimiento de las caracteristicas demograficas propiaes del programa en nos toque laborar concretamente. Los numeros publicados por Macromedia son una referencia global, y pueden no reflejar la verdad propia de vuestro publico objetivo. En ese sentido, las capacidades del reproductor que elijamos pueden tener distintos niveles de impacto en lo que los usuarios pueden (o no) ver o hacer. Estas son las razones que hacen necesaria la implementacion de cierta manera de deteccion del reproductor de Flash. Entre las alternativas que poseemos a vuestra disposicion, no tiene lugar un metodo 100% efectivo, ya siempre cabe la probabilidad de que la deteccion falle, ya sea por latencia en la red o limitaciones del metodo elegido. Los métodos ampliamente utilizados son tres: Flash MX 2004 Utilizando Flash MX 2004, es muy fácil configurar una película para que detecte que versión del plugin está instalada en el computador del usuario. Basta con dirigirse a la pestaña HTML del menú ?Publish Settings?, y marcar el casillero de Detección del reproductor. Los documentos HTML necesarios son creados automáticamente al publicar la película. Flash Detection Kit El kit de deteccion de Flash es un conjunto de dispositivos que proporciona distintos alternativas para detectar la version del reproductor de Flash en distintos escenarios. El kit incluye una expansion para Dreamweaver, ejemplos con codigo fuente para Actionscript y HTML, e inclusive una solucion para proyectores. Informacion detallada de como usar y descargar el kit, esta disponible en el sitio web de Macromedia Metodo Javascript Basado en desarrollos anteriores para la deteccion de Flash usando Javascript, Colin Moock desarrolla un metodo generico as cual llama Flash Player Inspector. 2. Brincar Intros (del todo) El de los tristemente celebres ?intros? es un clasico caso de justificacion, en Diseño. Generalmente, los intros suelen tener como meta impresionar al visitante haciendo derroche de creatividad, muchas veces en extremo. Entretanto que en determinadas ocasiones una pagina de origen puede ser necesaria para filtrar el publico meta o brindar informacion que los usuarios deben analizar antes de alcanzar a un website, en la mayor mayoria de los casos, su presencia es innecesaria y hasta inconveniente. Debemos comprender que los visitantes de un website o los usuarios de una aplicacion tienen un meta definido o tareas que quieren llevar a cabo. Si ponemos impedimentos innecesarios, lo mas posible es que estemos restandole eficiencia al esfuerzo de vuestros usuarios. Como opcion a los intros, ofrecer un demo o presentacion como fracción del contenido del website es recomendable. 3. Carga y precarga Dada la naturaleza cinematica de Flash, es siempre una buena idea asegurarse de que los contenidos esten cargados en sus respectivo fotogramas, antes de intentar mostrarlos. En una pelicula Flash, los fundamentos de cada cuadro deben estar disponibles antes de que el segmento pueda ser reproducido sin errores. Si, por ejemplo, el fondo de una aplicacion afuera una retrato de mayor tamaño, probablemente pasarian varios segundos antes de que la interfaz pudiera ser mostrada, especialmente si el usuario no cuenta con una conexion a Internet de alta velocidad. Aqui es donde el concepto de ?precarga? es introducido. Basicamente se trata de parar la reproduccion de una pelicula, hasta que alguna porcion del archivo ha sido cargado (no necesariamente el 100%), entretanto el usuario es informado del progreso, ya sea cuantitativa como cualitativamente. Entretanto que un simple mensaje de ?Cargando...? puede ser demasiado escueto, es probable caer en el absurdo de presentar la porcion de bytes cargados, bytes totales y restantes, tiempo transcurrido y restante, ancho de banda relativo, etc., todo a la vez, y pretender que para el usuario tenga sentido. No abandonar al usuario adivinando es importante, asi como lo es brindar informacion que le sea sobresaliente y facilmente asimilable. Por otro lado, para eludir largas esperas, es conveniente separar una aplicacion voluminosa en secciones menores, y usar un contenedor para cargar las fracciónes convenientemente. 4. Navegación La eficiencia de un sistema de navegación depende en mayor medida lo exitosa que haya sido la organización de la información. Discutir tópicos de Arquitectura de la Información no es el objeto de este artículo, pero si lo es la aspecto y funcionamiento de los fundamentos conformantes de un sistema de navegación eficiente. Innovar no significa tener que reinventar la rueda en cada proyecto, sino desarrollar sobre la fundamento de modelos existentes. En otras palabras, enriquecer las experiencias significa ser congruentes con lo que el usuario conoce y acepta. Por ejemplo, un boton debe parecer y actuar como los botones que resultan familiares a todos quienes hemos utilizado el computador cierta vez. Lamentablemente, la total libertad creativa que nos faculta Flash ha algun que se contravengan estas normas basicas, y que se publiquen articulos que rompen con los esquemas de manera negativa. Uno de mis maestros (en la musica) me dijo cierta vez, que para intentar romper las normas primero debia conocerlas muy bien. Este comienzo es igualmente significativo en el tema de la comunicacion visual: una vez que conocemos lo que funciona y lo que no, seremos capaces de ?doblar? las normas, sin romperlas. En su afan de protegernos de nosotros mismos, Macromedia ha venido integrando componentes de interfaz a las ultimas versiones de Flash, con el meta de uniformizar la forma en que nuestras aplicaciones lucen y funcionan. 5. Trabajando con texto Verdaderamente Flash es el standard de facto para la animación vectorial, es también una fuerte opción a otros plugins capaces de reproducir video en la web. Sin embargo, no es el mejor recurso para presentar masivos porciónes de inmaneración en manera de texto. Aunque la última versión del reproductor de Flash soporta un cierto grupo de características de las hojas de estilo CSS, permitiendo darle formato a campos de texto con contenidos tanto estáticos como dinámicos, el motor de procesamiento de textos todavía carece de capacidades que son nativas del standard HTML desde hace años. Por ejemplo, es imposible tener texto en dos columnas, a menos que se tengan dos campos de texto separados. Asimismo, es muy difícil predecir cuanto lugar ocupará una alguna porción de texto y establecer un método de paginación. Es por estas razones que sitios de noticias, y otros que necesitan presentar porciónes de texto significativas, suelen recurrir a soluciones híbridas. Otro causa es que el dimension del texto de una pelicula Flash no se ve afectado cuando el usuario determina cambiar el dimension de la fuente en las preferencias del navegador. Afortunadamente, es probable manipular en tiempo real ciertas propiedades de textos, incluyendo el dimension de la fuente, a traves del objeto TextFormat, tal y como se puede ver en este ejemplo. 6. Contenidos dinámicos Uno de los puntos establecidos por Jakob Nielsen en su apreciacion de los sitios extendidos en su totalidad con Flash, era que resultaba dificil mantenerlos actualizados, ya que era indispensable editar directamente el archivo fuente para hacer hasta el mas chico de los cambios. El dia de hoy, es consabido que tiene lugar una mayor variedad de tecnicas que nos facultan manipular datos desde Flash, tanto de acceso como de salida. Ya sea a traves de simples documentos de texto o XML, o gracias a la integracion de aplicaciones Flash con fuentes de datos dinamicos usando Flash Remoting y Web Services, es diáfano que presentar datos frescos en una aplicacion Flash es relativamente sencillo, una vez elegido el metodo adecuado. Probablemente escoger la tecnica a usarse sea lo que represente un desafio, ya que no siempre resulta sencillo. Muchas son las variables en juego y casi siempre vamos a tener que depender de la infraestructura, personal y conocimientos ya disponibles para vuestro equipo de trabajo. 7. Transferir ficheros Regulaciones de seguridad limitan el entrada del reproductor de Flash a funciones particulares del sistema operativo. Una de las mas reclamadas, es la capacidad de alcanzar a los archivos, y poder leer y escribir en el disco del usuario, mas alla de las limitantes de las supercookies de Flash. Es por este causa que no tienen lugar campos de archivo entre los componentes de interfaz ofrecidos por Macromedia, lo cual hace imposible que un formulario hecho en Flash pueda, por ejemplo, transferir un archivo desde el computador del usuario a un servidor remoto. Hace determinado tiempo, encontre este impedimento entretanto desarrollaba una solucion para un cliente. Mas tarde, ensayando una solucion general, introduje una tecnica basada en el esfueserzo conjunto de Flash, Javascript y PHP. El tutorial fuese publicado en After-hours.org, un sitio que sirve de punto de encuentro a fracción de la comunidad ?flashera? de Hablad hispana. Básicamente, se trata de usar un marco oculto donde ubicar tantos campos de archivo como nos hagan falta, y usar Javascript para establecer comunicaciones entre ambos marcos, el que esta oculto y el que alberga al formulario hecho con Flash. El rol de PHP está limitado a subir el archivo o ficheros al servidor, así que es intercambiable por cualquier otra tecnología que usen regularmente, ya sea ColdFusion, JSP, ASP, etc. 8. Aplicaciones Flash indexables Una de las preguntas que encontramos con gran frecuencia al escoger Flash para desarrollar un sitio, es si los usuarios podran encontrarlo en los buscadores. La respuesta no es siempre sencilla, pues depende de varios factores. Google, por ejemplo es capaz de indexar textos y seguir enlaces que se encuentren en una pelicula Flash. Al hablar de texto contenido nos referimos a texto que fuese introducido directamente en modo de edicion, no informacion recibida de fuesentes externas Determinadas soluciones, como ubicar textos de fuentes externas en manera de comentarios en el codigo HTML, suelen funcionar, entretanto que redireccionar spiders a paginas especiales es considerado abuso y puede repercutir negativamente en el posicionamiento de una web en los distintos motores de busqueda. Para ellos, no tiene lugar nada mejor que contenido sobresaliente y accesible. En ese sentido, aplicaciones hibridas (Flash/HTML) suelen tener los mejores resultados. Una opción usada para reemplazar encabezados por películas Flash, con el propósito de utilizar tipografía especial es sIFR. Extendido por Shaun Inman, Mike Davidson, Tomas Jogin y Mark Wubben, y actualmente en su versión 2, sIFR está empezando a ser usado por más y más diseñadores alrededor del mundo, incluyendo su servidor. Más información. Por otro lado SEFFS, extendido por Claus Wahlers e inspirado por sFIR, es una tecnica experimental que faculta procesar un documento XHTML y reemplazarlo por una pelicula Flash que lo procesa y redefine; luego de todo, XHTML es unicamente un tipo especial de XML. Más información. 9. Flash Accesible Usando Flash MX 2004 y su panel de Accesibilidad, es probable que algunos lectores de pantallas puedan detectar ciertos fundamentos de una pelicula Flash, y de esta forma hacerlos accesibles a personas con dificultades de vision. Sin embargo, esta caracteristica necesita la version 7 del reproductor de Flash, Microsoft Internet Explorer y un lector de pantalla compatible con la implementacion de Macromedia, actualmente Windows-Eyes de GW Micro, o JAWS de Freedom Scientific. Informacion detallada acerca de como construir aplicaciones Flash accesibles puede ser encontrada en el Macromedia Accesibility Center, y ejemplos de sitios creados con Accesibilidad estan disponible en este compendio publicado por Bob Regan. 10. Pruebas de Usabilidad Una evaluacion cualitativa de la Usabilidad de una aplicacion debe ser fraccion del proceso de diseño, y no del control de calidad, como suele ocurrir cotidianamente. No me atrevo a consignar un numero aqui, pero por la mayor mayoria de estudios de Usabilidad llevados a cabo en los Estados Unidos no tienen ningun valor, ya que al enterarse de las deficiencias de un sistema cuando esta terminado, es muy dificil beber acciones correctivas, respetando la probable ramificacion de sus repercusiones. Una evaluación cuantitativa o de casuística, que comúnmente se conoce como prueba de Usabilidad es lo que nos ayudará a decidir en que medida se cumplieron los objetivos. Como pueden ver, se trata de acciones complementarias, y no excluyentes. Entretanto que diseñar usa aplicacion teniendo al publico en mente no ayuda a establecer objetivos y cometer menos errores, o por lo menos errores menos fundamentales, una evaluacion del artículo terminado nos ayuda a decidir el nivel de Usabilidad alcanzado, corregir errores mas manejables, y documentar lecciones aprendidas. La envergadura de estas evaluaciones siempre dependera del presupuesto disponible, pero es indispensable tenerlas en cuenta para la asignacion de recursos. Determinadas firmas eligen que las pruebas de Usabilidad sean llevadas a cabo por empresas especializadas, o debajo la direccion de un consultor. Cualquiera sea el caso, es significativo destacar que vuestra participacion como artículores de contenido es critica: la mejor consultoria de Usabilidad del mundo no conoce vuestro artículo mejor que nosotros mismos.

Las areas de Tecnologia y Sistemas de Informacion de las masivos compañías son conscientes de los beneficios de la "normalizacion" de interfaz en cuanto a su aspecto. En masivos departamentos de tecnologia integrados por equipos variados y numerosos cada uno con sus propios usos y metodologia normalizar supone un cambio de metodologia de esfuerzo que debe abordarse desde una perspectiva global e integradora. La demanda de aplicaciones de negocio de interfaz web y su apertura tanto a usuarios internos como externos (entranet, internet) y la situación de inconsistencia entre ámbitos ha despertado una especial sensibilidad por el diseño gráfico y la normaliziación. El primer paso hacia la normalización suelen ser los "Libros de Estilo" y los mal llamados "Manuales de Usabilidad". Qué es una Guía de estilo Es un documento que recoge normativas y patrones básicos relacionados con el "aspecto" de un interfaz para su aplicación en el desarrollo de nuevas "pantallas" dentro de un ámbito concreto. (sitio web de contenidos, nuevas secciones, ámbito de aplicaciones de negocio). Hemos dicho "aspecto". ¿Desde qué otras perspectivas debería abordar una "Guía de Estilo"? Conceptualmente, el interfaz de usuario descansa en 3 puntos: Significado (que): es la fundamento del interfaz. Recoge el contenido o informacion de la pantalla. Textos, campos de formularios, botones, menus... Comportamiento: trata el funcionamiento del interfaz. Cómo se comporta cuando un usuario envía un formulario (validaciones), hace clic en un enlace... Aspecto: aspecto final de un sistema: colores, tipografía, dispocición de los elemepntos en pantalla (layout). Las Guías de Estilo, generalmente se centran en el "Aspecto". Puntos como diseño y maquetación (colores, tipografías y píxeles), y apenas incluye criterios o casuística para aplicar en el proceso de diseño de interfaz ("Significado"). Las Guías de Estilo no son Manuales de Usabilidad A menudo se confunde el término "Guía de Estilo" con "Guía de Usabilidad" y un cambio de diseño lleva a definirse como una "nueva usabilidad". ("Necesitamos modificar las aplicaciones antiguas a la nueva usabilidad" (sic)). Hay personas que identifican "aspecto" y "usabilidad": esto lleva a que dos aplicaciones pueden ser radicalmente opuestas en usabilidad cumpliendo ambas las pautas de una "Guía de Estilo". Poniendo por ejemplo un coche: Desde una perspectiva de "significado" un coche se adapta a un uso por sus características (carretera, familiar, pequeño, todoterreno, descapotable) y no por su color ("aspecto"). Identificar "usabilidad" y "diseño" equivale a decir: - "Quiero un coche rojo." - "¿Para que lo quieres? Carretera, montaña, niños..." - "¿Qué más da? Que sea rojo." Para que una Guía de Estilo pueda convertirse en un manual de usabilidad debería tocar puntos relacionados con "significado" ofreciendo criterios para, dentro de un estilo definido, seleccionar las características que se adapten al destino final de una aplicación (objetivos+usuarios+contexto). Destinatarios de las Guías de Estilo Las "Guías de Estilo" son creadas inicialmente como documentos voluminosos muy vistosos que ilustran sobre la aspecto del interfaz de un sistema. Su asunto mas gravisimo es su falta de usabilidad: Están pensadas desde una perspectiva de diseño y márketing y no tienen en cuenta las necesidades de sus verdaderos destinatarios: *Diseñadores y Programadores de interfaz*. Una buena Guia de Estilo, debe integrarse de forma eficiente en el proceso de esfuerzo de un programador ofreciendo criterios y ayudando en la coge de decisiones en apariencias de diseño de interfaz. No deben ser una carga: han de ir acompañadas por acciones de promoción y formación y materiales de apoyo que ahorren esfuerzo al programador. Caracteristicas de una Guia de Estilo provechoso Una Guía de Estilo debería abordar la perspectiva del "significado" del interfaz. Usable: invitar al uso. Debe integrarse de manera comoda en el proceso de esfuerzo de un desarrollador dandole respuestas a situaciones particulares dentro de la construccion del interfaz de una aplicacion. Visual: huir del texto. Por experiencia, una Guia de Estilo no se usa, y esta posibilidad se reduce drasticamente cuando se cimienta en texto lo que lleva a una desactualizacion y abandono. Educativa: rica en ejemplos aplicables Y RAZONADOS que permitan construir criterios minusculos de usabilidad y estetica al personal tecnico. Actualizada: debe contener ejemplos útiles, actuales y materiales para su aplicación directa disponibles a través de repositorios. Dificultades de las Guías de Estilo: nadie lee La experiencia demuestra que los equipos de desarrollo no se apoyan en las "Guías de Estilo" para hacer su trabajo. Razones: Resultan demasiado abstractas y simplistas: se crean desde áreas (márketing, negocio...) que carecen de visión de la complejidad del esfuerzo del desarrollador obviando su problemática cotidiana. Falta de adecuacion a los metodos de desarrollo: El desarrollador no tiene tiempo para leer ni asimilar una documentacion que asimismo de ser voluminosa, le resulta ajena. Demasiado detalle: la documentación entra en cuestiones de detalle (pixels de separación entre elementos, tipografías, colores y valores hexadecimales) impropias del esfuerzo de un desarrollador. Falta de mantenimiento consistente: no tiene lugar una politica de mantenimiento del Manual con una vision integradora de todo el proceso de desarrollo. Falta de apoyo: la Guía se publica sin acciones de promoción, formación y apoyo. La documentación caduca por no uso con lo que se vuelve a una situación parecida a la de partida. No tienen utilidad real: no se promueve la reutilización de soluciones (conocimiento, componentes) entre los distintos equipos de desarrollo. Crear una Guía de Estilos Construir una "Guía de Estilo" es un primer paso hacia un cambio cultural en las metodologías de desarrollo que deriva en la adopción de técnicas de Diseño Centrado en el Usuario. Es indispensable un equipo unico de especialistas en interfaz de usuario con vision horizontal integradora del conjunto de sistemas y procesos de desarrollo que garanticen un ámbito de aplicaciones consistente. Los cometidos de este equipo son: Documentar: crear documentación de carácter visual, compuesta de literatura esencial, ejemplos razonados. Formar: dar charlas introductorias, cursos breves periodicos con el meta de construir un criterio de usabilidad. Dar soporte: desde el arranque hasta el cierre del programa resolviendo dudas, detectando nuevas necesidades que se puedan plantear e incorporándolas a la Guía. Detección de patrones: identificación de patrones que puedan derivar en componentes de interfaz reutilizables para su uso por los distintos equipos de desarrollo. Para abstraer al programador de tareas de diseño, estos objetos deben llevar embebidos apariencias visuales y esteticos. Deben ser puestos a disposicion de los equipos de programacion a traves de un repositorio unico actualizado. Investigacion e innovacion: tener identificados patrones reutilizables y componentes libera recursos de hacer tareas repetitivas y de poco valor añadido para la deteccion de lineas de mejora del interfaz, metodologia y procesos de desarrollo. (Adecuacion a estandares tecnicos, accesibilidad, mejoras, tecnologias alternativas). Programar y hacer tests y pruebas con usuarios: conocer la apreciación de los usuarios de las soluciones incorporadas permitirá hacer correcciones e introducir mejoras.

Siempre se Hablad de masivos webs porque pensamos que hay que aprender de los mejores, pero verdaderamente estos programas a simple vista parecen escaso utiles para muchos desarrolladores que en su dia a dia crean webs para pequeñas compañías y negocios sin ninguna pretension especial mas que "estar en eso de la Internet". Por su simplicidad en secciones y contenidos estas pequeñas webs son bastante usables "per se", por lo que no es muy sobresaliente si el color de los links es estandar o no. Sin embargo si son significativos los apariencias de usabilidad "estrategica" o global, es decir, el planteamiento común de la web en su enfoque al visitante (potencial cliente) y su utilidad para complementar el negocio. Una web que no sirve para nada Si lo piensas demasiado veloz la web del concesionario de coches de la esquina no parece que pueda servir para nada. Nadie compra un coche por Internet y para informarse sobre los modelos es mas general ir a la web de la mayor marca. Asi cuando el responsable del concesionario de la esquina desea que le hagamos una web, parece que la maxima es una web "como sea, pero bonita para que quede contento". Con semejantes premisas, el sendero al desastre parece seguro. Crear una web que no sirve para nada no tiene ningun sentido, por tanto vuestra tarea principal es convertir la web de esta compañia en algo de utilidad para los clientes y que aporte beneficios al compañiario. Es cuestion de pensar en situaciones donde tenga sentido que la web ayude tanto a la compañia como a los clientes. En el caso del concesionario es posible que alguien pueda estar buscando un concesionario de esa marca en las cercanias del espacio donde vive, usualmente utilizara Google y escribira algo como "marca + localizacion", por ejemplo "Renault en Getafe". Por tanto algo tan facil como incluir muy visible y en el titulo de la homepage la situacion del concesionario y la marca puede ayudar mucho. Del mismo modo un mapa en la homepage que explique la situacion exacta y como llegar de variadas formas (metro, autobus, coche...) puede realizar que lleguen clientes al concesionario que de otro modo jamás se hubieran acercado. Si vamos más allá se puede pensar, por ejemplo, en un sistema de envio de e-mails o SMS a los clientes para recodarles revisiones periódicas; cambios de aceite, filtros o neumáticos que la gente suele olvidar con el consiguiente riesgo para ellos y perdida de ingresos para el concesionario. Estar un par de horas en el concesionario observando, unas preguntas al responsable del negocio, a los trabajadores o simplemente tratar de ponerse en el espacio de un cliente nos puede dar muchas ideas sencillas e interesantes. En este tipo de negocios donde lo significativo es la fraccion offline, la fraccion online no tiene sentido que sea planteada como un sustituto o una replica del negocio (vender coches), sino como un apoyo, un complemento para las fraccions donde el negocio fisico tenga dificultades (olvido de revisiones periodicas). Una home provechoso y que "enganche" Nada más inútil que una homepage de bienvenida con un botón "Entrar" o ni nada más decepcionante que una home vacia con solo vínculos a las cuatro típicas secciones (quienes somos, productos, clientes y contactar). Estas homes no generan acción ni motivación en el visitante. Verdaderamente cuando hay 4 secciones nadie se va a perder en la web y encontrará toda la información fácilmente, sin embargo ¿por que crear una página de origen que no sirve para nada? ¿no sería mejor aprovechar la homepage para presentar contenidos? El paradigma de páginas de origen extremadamente útiles y claras es Avidos.net. En una sola página explican todo lo que hacen, sus clientes y proyectos. En un vistazo ya está todo dicho. No hay probabilidad de perder ni un solo cliente potencial que visite la web por falta de motivación para investigarla. Evidentemente no todas las homes pueden ni deben ser idénticas a la de Avidos.net, pero incluir esta información en la homepage tiene muchas ventajas: Presentar tus clientes directamente en la homepage genera confianza en los visitantes (potenciales clientes) que no te conocen, que aterrizan en tu web desde Google (lo más probable) y que no tienen la motivación necesaria para navegar por las secciones. Tambien genera confianza presentar directamente en la home fotos reales de la compañia, el equipo de personas, la direccion fisica y el telefono. Esto da sensacion de cercania y de una compañia fisica. Nada peor en la web de una pequeña compañia que las tipicas fotos del ejecutivo encorbatado con un Pocket PC en la mano y una secretaria tipo top-model respondiendo al telefono. No hay mejor referencia para los clientes que tu propio trabajo. Incluir en la home ejemplos y vínculos a esfuerzos realizados es más positivos para obtener clientes que los típicos textos insípidos "empresa líder en el sector" o "nuestro compromiso con la calidad". Una web con todos estos contenidos en la home no tiene porque ser forzosamente menos atractiva que otra. Hay mil formas de mostrar estos contenidos de forma atractiva. Lo que no funciona es primero pensar en el diseño grafico y despues en para que sirve la web. Lidiando con la compañía Verdaderamente un empresario que simplemente "quiere estar en esto de la Internet" no va a comprender lo significativo de estar en Google o lo significativo que es crear una web que sirva realmente para algo a sus clientes, pero para eso estamos nosotros y para eso nos pagan. Olvidarse de eso es pan para hoy y hambre para mañana. Una alternativa que personalmente me gusta, pero no aconsejo demasiado, es tratar de enseñar al cliente y explicarle las cosas pacientemente. Es un esfuerzo duro y escaso gratificante porque inicialmente no entendera nada. sin embargo cuando lo entienda saldremos ganando en todos los aspectos. Otra alternativa es la via de los hechos a posteriori. Una pequeña compañia no entiende lo significativo que puede ser Google para ellos hasta que no les llega un cliente que dice que les ha encontrado en Google. Que ese cliente le llegue o no depende del esfuerzo que hayamos hecho nosotros antes. Crear una web que no sirve para nada mas que "estar en Internet" y que es ignorada por Google, es tener un cliente satisfecho en ese momento, pero que dificilmente nos volvera a emplear porque no percibira beneficio. Gestores de contenidos La mayoria de webs de pequeños programas actualmente se hacen sin un Gestor de Contenidos (CMS). Esto provoca que sea indispensable emplear a un desarrollador cada vez que se quieran actualizar contenidos de una web. Crear webs estaticas con Dreamweaver es anacronico hoy en dia, el fruto son webs que no se actualizan en años, es un atraso. Los gestores de contenidos han hecho que publicar sea tan sencillo como enviar un e-mail. Cualquier persona de la compañia sin conocimientos puede publicar en la web. Esto faculta convertir inclusive las webs mas modestos en algo vivo, cambiante y actualizado. Tener autonomia para cambiar contenidos involucra al cliente en Internet y crece su comprension del medio. Pensar que se pierde dinero si el cliente no nos requiere para actualizar su web no es acertado. Un cliente que se acostumbra a publicar de forma autonoma, se familiariza con el recurso y de forma natural le aparece la necesidad de rediseñar su web frecuentemente, agregar secciones y funcionalidades, de tal forma que acaba requierendo a los desarrolladores web inclusive mas que antes. Un gestor de contenidos es el primer paso para integrar Internet escaso a escaso en su negocio. Las prioridades en un chico programa Hace escaso en un foro de diseñadores gráficos de la vertiente más estética, al relatar una web de venta de vinos sencilla y bastante centrada en el usuario se decía entre otras cosas "la veis y no te entran ganas de tomarte un vino, le falta feeling". En mi opinión esto es confundir prioridades y funcionamiento de una web. Una web de vinos no tiene como meta prioritario incitar a tomar vino, sino vender vinos y dar información sobre ellos, al idéntico que un cajero automático no se crea principalmente para incitar a la gente a que saque dinero, sino posibilitar que lo saque. En ambos casos no hay que crear ninguna necesidad porque si el usuario llega al cajero o a la web, ya tiene la necesidad. Cuando los recursos son pocos como en programas web de pequeñas empresas, centrarse en los apariencias criticos y no desaprovechar trabajos en fundamentos de dudosa influencia es crucial para el exito. Hay que evaluar el ratio coste/beneficio de cada iniciativa y laborar en lo que realmente puede dar resultados, en este caso, el proceso de venta. Flash y animaciones Muchas pequeñas compañias desean para su web una presentacion en Flash y animaciones. Cierta gente identifica incorrectamente los ordenadores e Internet como algo similar, quizas porque ambos se visualizan en un monitor. Se han dado mil argumentos acerca de uso y abuso de Flash, pero al empresario le suele dar idéntico porque no conoce a Jakob Nielsen. A nosotros puede que también nos importe escaso usar Flash bien o mal, lo que nos importa es que el cliente quede contento y nos pague. Sin embargo eso no implica forzosamente interpretar sus peticiones al pie de la letra e implementar la solución más fácil. Ni siquiera Macromedia, el creador de Flash, tiene su pagina web totalmente hecha en Flash. Es mejor usar Flash solo para lo que realmente requiera animacion o mucha interactividad. Una web totalmente hecha en Flash puede provocar que la compañía no aparezca en Google ni buscandola explicitamente por su nombre. Y ya se sabe, si no estas en Google, no estas en Internet. Si hay que realizar una animacion obligatoriamente para contentar al compañíario que nos paga, hagamosla de algo provechoso o interesante; el proceso de preparacion de un producto, la cadena de montaje, un tutorial explicativo o la historia de la compañía, en definitiva, algo que aporte a los visitantes. Las animaciones gratuitas tipo el logo de la compañía moviendose estilo Star Wars no sirven para nada ni interesan a nadie. ¿Mostrar los contenidos o la web en si misma? Un libro puede hablar de arte, pero eso no significa que haya que convertir el libro en un objeto de arte tambien. De idéntico modo una web cuyos contenidos sean artisticos no tiene porque ser forzosamente un objeto de arte. Si una web se convierte en un objeto de arte, entonces el meta del creador no es presentar lo que la web contiene, sino la web en si misma. Algunos diseñadores graficos piensan que su web, por contener su trabajo, que en fracción suele ser artistico, debe ser tambien una presenta de su arte e impresionar a toda costa al potencial cliente que visita la web. Creo que esto es un error. Raramente una pequeña compañia desea una web parecida a la del diseñador (o no deberia quererla). Usualmente el agente principal que hace emplear al diseñador seran sus esfuerzos anteriores, portafolio, referencias, curriculum, etc. Esta bien que una web impresione a potenciales clientes, pero no tanto que se convierta en un juego ver el portafolio o descubrir el e-mail del diseñador. Si habeis hecho una animacion genial, darle un entrada diafano a la animacion desde la home es la mejor forma de potenciarla, ni ocultarla dentro de un menu desplegable ni realizar que el usuario tenga que navegar a traves de otra animacion para encontrarla.

A nadie le gusta estar horas discutiendo el nombre de un enlace, su posicion o su color, sin embargo un minimo cambio en estos apariencias puede ser la diferencia entre un servicio que funcione y otro mediocre. En este artículo hacemos un repaso a algunos de los fundamentos que pueden marcar la diferencia. La visibilidad de los vínculos críticos: Un vínculo con el texto perfecto y la posición perfecta en la página, puede pasar desapercibido si no es suficientemente visible. La visibilidad puede ser muy distinto por un par de milimetros mas o menos en el lugar en blanco alrededor del vinculo. Igualmente por un chico cambio en el dimensión de la fuente o por una minima diferencia de contraste con el fondo. Por ejemplo, si un vínculo está demasiado resaltado, sobre un color de fondo demasiado intenso o pegado a un fundamento decorativo, puede ser ignorado. No hay normas universales para crecer la visibilidad de un vínculo porque depende del contexto donde se sitúe, pero pequeños detalles como los comentados pueden marcar la diferencia entre obtener la visibilidad exacta que el vínculo merece y no hacerlo. Vínculos que generan acción: En ocasiones el flujo común de la interacción esta bien diseñado y es usable, pero simplemente el vínculo que comienza el proceso es demasiado haragán o no es el adecuado. Un detalle de este tipo puede echar por tierra un mayor trabajo. La diferencia entre el clásico "Regístrate" y un verbo más cercano a la acción real del usuario, puede suponer una mayor diferencia en el número de clicks sobre el vínculo. "Abrir una cuenta" (en un banco online) o "Comprar" (en una tienda), son más correctos que el clásico "Regístrate", un término técnico muy vago. Un vínculo más cercano al meta real del usuario generará más tráfico que un término técnico como "Regístrate" que solo tiene sentido en algunos casos como los webmails. Laborar en equipo: Cuando se labora en equipo no es factible que alguien (en este caso el especialista en usabilidad) tenga la ultima palabra siempre, inclusive aunque tuviese siempre razon. Por razones practicas se debe ceder en unas àreas para ganar en otras. Tener diafano los fundamentos criticos donde no se puede ceder y donde si se puede hacerlo, es vital para que el fruto de la negociacion sea un sitio que funcione. Para no ceder en los apariencias criticos hay que disponer una municion argumental potente y estar dispuesto a emplearla, lo que puede provocar que vinculos entre los miembros del equipo se tensen. Una tactica interesante para solucionar este tipo de conflictos es ceder a contenidos escaso centrados en el usuario areas que a priori parecen muy visibles, pero en verdad no lo son. De este modo no interfieren con el usuario, pero los miembros del equipo que las demandan quedan satisfechos. Áreas de este tipo son la columna de la derecha y la cabecera. Parecen muy visibles, pero en verdad son areas a las que los usuarios presentan poca atencion. El analizo de Eyetracking (seguimiento de movimientos oculares) del Poynter Institute ilustra las areas mas y menos significativos de un sitio web. El nivel de acabado de los prototipos: Usualmente el equipo, especialista o encargado de la usabilidad no entrega html acabado, sino prototipos. Despues otro proveedor se encarga del desarrollo y del diseño gráfico. Cuanto gran es el nivel de acabado del prototipo menos riesgo hay que despues en el desarrollo se altere el esfuerzo de usabilidad anterior. Evidentemente a gran nivel de detalle, mas esfuerzo y mas caro resulta el prototipo. Sin embargo, si el nivel de detalle no es suficiente, los desarrolladores se tomaran "libertades" para los fundamentos no especificados, con el riesgo que esto supone para la usabilidad del sitio. Una alternativa para no incrementar excesivamente el coste es crecer el nivel de detalle, no en todos los prototipos, sino en los de usabilidad mas critica. El coste de la precisión: Que una o algunas personas dediquen una o algunas jornadas de esfuerzo a discutir sobre la posicion exacta de un par de vinculos, su color o su texto en el sitio, supone un alto coste en tiempo y dinero. No todos los fundamentos de un sitio web necesitan de tanta precisión, pero algunos verdaderamente sí. La relevancia de la exactitud en esta disciplina conlleva que la usabilidad dificilmente pueda ser barata.

Se podria decir que, en el diseño de un sistema, hay tres apariencias a tener en cuenta: la presentación de la información la funcionalidad de la aplicación la Arquitectura del Software Hasta hace poco, se asumia que la usabilidad era una propiedad exclusiva de la presentacion de la inmaneracion. Se creia que, encapsulando la capa de presentacion y separandola del resto, se permitia construir la aplicacion y, de manera iterativa, pasar los tests de usabilidad. Tras cada test, tan solo seria indispensable resolver los dificultades modificando la presentacion y, gracias a esta separacion, la funcionalidad no quedaria afectada. En realidad, este modelo de desarrollo ha fallado a menudo. ¿Cuantas veces hemos tenido que correr a hacer cambios profundos en la funcionalidad de una aplicacion despues de haber detectado dificultades de usabilidad? Dick Berry, en su analogia del Iceberg de la usabilidad, explica que los apariencias relacionados con la presentacion, es decir, lo que usualmente entendemos como look & feel, solo afectan en un 40% a la usabilidad. El 60% restante esta influenciado por lo que el llama ?modelo del usuario?, que esta constituido por los metas que el usuario desea conseguir con sus tareas. Berry relaciona el modelo del usuario con el modelo de objetos propio de la interfaz de usuario, en el sentido estricto de la OOP (programacion enfocada a objetos), que incluye, entre otras cosas, los objetos y las metaforas de la interfaz. Este modelo de objetos, siempre segun Berry, es el que faculta al usuario relacionar sus metas con la funcionalidad del sistema. Por lo tanto, y esto ya es de cosecha propia, para obtener una buena usabilidad, no basta con tener en cuenta la capa de presentación, sino que es preciso que la usabilidad se contemple también en el momento de la definición de la funcionalidad de la aplicación. Usabilidad y Arquitectura del Software Sin embargo, a menudo hay que ir mas lejos y no basta con tener en cuenta la presentacion y la funcionalidad. Sobre todo en sistemas complejos, como pueden ser los ambitos distribuidos, los transaccionales, los multicanal y aquellos en los que puede haber miles de usuarios conectados simultaneamente, hay que tener en cuenta la usabilidad desde el origen del diseño del sistema, es decir, desde lo que se designa momento de Arquitectura del Software. Es bien sabido por los ingenieros del software que cuanto más tarde se detectan los problemas, más cuesta arreglarlos. ¿Cuántas veces nos ha pasado que, al diseñar una interfaz, desearíamos crear interacciones y diálogos que el ámbito tecnológico no nos permite? Y siempre acabamos exclamando: ¡Pero si esto mismo lo hice en tal otro sitio! La respuesta de los técnicos no se hace esperar y, utilizando un vocabulario lleno de siglas y conceptos técnicos, nos dicen que en su plataforma esto no es posible. Me refiero a cosas como que el usuario pueda visualizar el progreso de sus peticiones, que pueda deshacer acciones (undo), que pueda disponer de un entono multilingüe, que pueda cancelar una operación que lleva mucho tiempo en espera, que pueda reutilizar información que ha introducido anteriormente, y muchas otras cosas. Si analizamos estos escenarios de interaccion, veremos que la motivo de que no se puedan implementar es que no se tuvo en cuenta al usuario al origen del diseño del sistema, es decir, en la Arquitectura del Software. ¿Que es la Arquitectura del Software? Tienen lugar muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podriamos estar de acuerdo en que la Arquitectura del Software es el diseño de mas alto nivel de la articula de un sistema, proyecto o aplicacion y tiene la responsabilidad de: Definir los módulos principales Definir las responsabilidades que tendrá cada uno de estos módulos Definir la interacción que existirá entre dichos módulos: Control y flujo de datos Secuenciación de la información Protocolos de interacción y comunicación Ubicación en el hardware La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a pasos posteriores del diseño. La definicion oficial de Arquitectura del Software es la IEEE Std 1471-2000 que Rezad asi: ?La Arquitectura del Software es la organizacion importante de un sistema constituida por sus componentes, las vinculos entre ellos y el contexto en el que se implantaran, y los comienzos que orientan su diseño y evolucion?. Los artículos resultantes de la Arquitectura del Software El meta principal de la Arquitectura del Software es aportar fundamentos que ayuden a la coge de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje general que permitan la generalicacion entre los equipos que participen en un proyecto. Para conseguirlo, la Arquitectura del Software construye abstracciones, materializandolas en manera de diagramas (blueprints) comentados. No hay estandares en cuanto a la manera y lenguaje a utilizar en estos blueprints. De todas maneras, tiene lugar consenso en cuanto a la necesidad de estructurar felicidades abstracciones en vistas, tal y como se hace al diseñar un edificio. La porción y tipos de vistas difiere en funcion de cada tendencia arquitectonica. Quiza uno de los modelos mas conocidos es el ?4+1? de Philippe Kruchten, asociado al Rational Unified Process (RUP), que determina cuatro vistas diferentes: Vista logica: detalla el modelo de objetos. Vista de proceso: presenta la concurrencia y sincronía de los procesos. Vista física: presenta la ubicación del software en el hardware. Vista de desarrollo: detalla la organizacion del ámbito de desarrollo. Tiene lugar una quinta vista que consiste en una seleccion de casos de uso o de escenarios que los arquitectos pueden elaborar a dividir de las cuatro vistas anteriores. Ejemplos de Arquitectura del Software: J2EE y MVC Para ilustrar un escaso lo que se ha explicado hasta ahora, a continuación se muestran dos diagramas de arquitectura en un ámbito J2EE. Ambos diagramas están disponibles en Designing Enterprise Applications with the J2EE Platform, Second Edition. El primer diagrama consiste en una vista lógica que presenta los componentes y servicios típicos de un ámbito J2EE. El segundo diagrama es una vista de proceso que presenta las vinculos entre las capas model, view y controller de la arquitectura MVC debajo J2EE. La investigación sobre Arquitectura del Software y Usabilidad El interes por la relacion entre Arquitectura del Software y usabilidad no es nuevo, pero recientemente han aparecido algunos esfuerzos que abren el sendero a la practica del fruto de las investigaciones. Este año, tanto en Viena, en la Conference on Human Factors in Computing Systems (CHI2004), como en Edimburgo, en la International Conference on Software Engineering (ICSE04), un equipo liderado por Len Bass ha impartido un tutorial sobre el tema, cuyo titulo es bastante ilustrativo: Avoiding ?We can?t change THAT!?: Software Architecture & Usability (Como eludir ?¡Esto no se puede cambiar!?: Arquitectura del Software y Usabilidad). En el equipo docente, junto a Bass estaban Bonni E. John y dos investigadoras españolas, Natalia Juristo y Maribel Sanchez-Segura. Escenarios de usabilidad sensibles a la Arquitectura del Software El esfuerzo de Bass y de este equipo se cimienta en inventariar una serie de escenarios de usabilidad sensibles a la Arquitectura del Software. Esto implica decidir una serie de momentos de interaccion o tareas del usuario que, para que el sistema los pueda soportar, tienen que estar definidos en la Arquitectura del Software. Hasta el momento, este inventario está compuesto de 26 escenarios que se pueden consultar en el documento CMU/SEI-2001-TR-005 de Bass y otros. La lista completa es demasiado extensa para el meta del presente artículo pero, a modo de ejemplo, se enumeran a continuación los cinco primeros escenarios: Agregación de datos: Poder aplicar simultáneamente una acción a un conjunto de datos u objetos. Agregación de comandos: Agrupar acciones que se puedan ejecutar de una sola vez. Comandos de cancelación Uso de aplicaciones de manera concurrente Validación automática de la acceso de datos Patrones arquitecturales Bass continua con una propuesta de patron arquitectural para cada escena (sobre el asunto de patrones, consultad el producto de Luis Villa, Patrones para el diseño de interfaz, publicado en Grancomo). El meta es doble: Facilitar a los entendidos en usabilidad una checklist con escenarios que muestre apariencias de usabilidad significativos a tener en cuenta en tiempo de requerimientos. Facilitar a los arquitectos patrones que los guíen en el momento de dar soporte a los escenarios. Otro documento interesante es: Patrones de Usabilidad: Mejora de la Usabilidad del Software desde el momento Arquitectonico (PDF), de Natalia Juristo y Maribel Sanchez-Segura. Una de las aportaciones mas interesantes de este documento es que detalla el procedimiento de obtencion de los patrones de usabilidad que han de servir para desarrollar los patrones arquitectonicos.

1. Procura utilizar imágenes agrupadas. Ocupan menos y tardan menos en bajar. Si tienes un menú tipo pestañas o botones, es mejor si agrupas todas las imágenes en un solo documento tipo GIF y en el mapa de la imagen incluyes el tag de "title" para cada zona. El hecho de agrupar las imágenes hará que pese menos y bajará más rápido. Si las separas en trozos, realizarás muchas peticiones al servidor haciendo que la bajada de documentos se retrase y el total de ficheros a bajar ocupe más. Algunos sites que hacen uso de imágenes separadas: Apple.com Adobe.com - adobe.com ya no emplea una imagen separado por boton. Actualmente la barra de navegacion es una unica imagen que usa un mapa. Actualmente los mapas de imagenes facultan crear "title" por zonas de tal manera que el usuario que no descarge las imagenes sera capaz de usarlos igualmente. Algunos sites que hacen uso de imágenes agrupadas: Amazon.com,Yahoo.com 2. No useis iconos. Exigen mas trabajo de aprender y nadie los entiende. Tiene lugar la proximo regla por fracción de la gente de SIDAR.org: "Los iconos no son siempre comprensibles para personas con limitaciones psíquicas. Además si sólo fueran gráficos resultarían inaccesibles a personas con discapacidad visual que utilicen lectores de pantalla." Si esta regla no es suficiente para reducir el uso de los iconos en la web, el segundo causa es que nadie se va a aprender el funcionamiento de tu sitio. Procura colocar las cosas claras evitando ejercicios de memoria inutiles.

¿Qué es la analítica web? La analitica web consiste en grabar y considerar los datos de navegacion de los usuarios en un sitio web. En un primer momento, se utilizaban los datos grabados en los logs de los servidores. Actualmente, la mayoria de las dispositivos de analitica web funcionan mediante un codigo javascript que se inserta en el pie de pagina, y que recoge los datos que nos interesen para enviarlos a una fundamento de datos que posteriormente podremos consultar. Las dispositivos profesionales mas conocidas son: Google Analytics Omniture SiteCatalyst XiTi Nedstat Visual Sciences WebTrends ClickTracks Clickdensity ¿Qué mide la analítica web? Las principales medidas (metricas) de cualquier dispositivo de analitica web son: Páginas vistas Usuarios Únicos Visitas Tiempo de navegación Otros datos que manejan determinadas dispositivos de analitica web son: datos de clicks ("clickstream") que facultan reconstruir las rutas de navegacion de los usuarios asi como retratar "mapas de calor" sobre una pagina, mostrando los fundamentos con mas clicks euros (por ejemplo, en un sitio de comercio electronico, el importe de una compra; en un sitio de contenido, el valor de un click en un aviso o de la impresion de un banner) inicios del trafico: es decir, los sitios web que nos envian visitas, asi como las palabras clave que los usuarios emplean en los buscadores para llegar a vuestra web páginas de entrada: es decir, la página por la que un usuario entra en vuestro sitio páginas de salida: es decir, la página desde la cual un usuario abandona vuestro sitio eventos del sitio web: por ejemplo, número de usuarios que se facturan para recibir un newsletter, número de usuarios que hacen una búsqueda, número de formularios enviados, etc. abandono de formularios: número de veces que un formulario se empieza a rellenar y se abandona, así como el tema en el que se abandona el formulario Si los interesa profundizar en el asunto de la analitica web en general, en esta pagina web de mi compañía he recopilado algunlos recurslos de analitica web, como por ejemplo un interesante gllosario de terminlos de analitica web (en ingles) elaborado por la Web Analytics Association, cuya pagina web es por supuesto de consulta indispensable. Analítica web y Usabilidad Tienen lugar muchas tecnicas y procedimientos que nos facultan aprovechar los datos recolectados por una dispositivo de analitica web a fin de mejorar la usabilidad de un sitio web. Nos centraremos en los próximos puntos: ClickMap A/B Testing Análisis de formularios Rutas de navegación ClickMap El "clickmap" (mapa de clics) es aparentemente semejante a los mapas de calor del 2eye tracking", pero en espacio de mostrarnos donde miran los usuarios, nos presenta donde hacen clic los usuarios. Determinadas versiones del "clickmap" sólo muestran datos de clics en las zonas clicables (links, botones), como es al caso de la funcionalidad llamada "site overlay" de Google Analytics. Otras dispositivos como Clickdensity, sin embargo, son capaces de presentar datos de clic en cualquier zona de la pantalla, independientemente de si tiene un link o no (os aconsejo que probeis la demo de Clickdensity, vale la pena) Finalmente, dispositivos como Omniture SiteCatalyst pueden presentar los ingresos que genera cada clic en cada fundamento de la pagina. Ademas, es capaz de presentar datos en tiempo real. La utilidad del mapa de clics es evidente: de un vistazo, podemos ver donde clican los usuarios en una pantalla determinada, y rapidamente actuar para mejorarla en tres apariencias principales: Visibilidad y posicionamiento de links y botones de la página Fundamentos de la página que confunden al usuario: aquellas zonas de la página en donde hay muchos clics, a pesar de que no son clicables Fundamentos de la página más "rentables": no está directamente relacionado con la usabilidad, pero usualmente querremos dar más visibilidad a aquellos fundamentos más rentables, así como investigar por qué ciertos fundamentos de la página no son tan rentables como esperaríamos A/B Testing El A/B Testing es de utilidad cuando dudamos entre dos diseños para una misma pagina. Lo que haremos es ubicar ambas versiones de la pagina en el servidor, y utilizar una dispositivo de analitica como Omniture SiteCatalyst o Google Optimizer para comparar los frutos de ambas paginas. Por ejemplo, podremos comparar: Ratios de conversión del meta de la página: por ejemplo, si el meta de la página es que el usuario rellene un formulario, compararemos el número de usuarios que rellenan el formulario en cada versión de la página Ratio de abandono: si el meta de la página es invitar al usuario a moverse por el sitio web, podremos comparar los ratios de abandono de las dos versiones de la página Asi mismo, el A/B Testing lo podemos utilizar para comparar el fruto de una misma pagina en periodos de tiempo distintos, por ejemplo: antes de aplicar un rediseño a la página el día después de subir la página rediseñada una semana después un mes después Podremos así sacar conclusiones acerca de: El éxito o fracaso del rediseño, según si se cumplen mejor o peor los metas de la página El tiempo de aprendizaje de los usuarios: ¿cuánto tiempo tardan los usuarios en modificarse a un nuevo diseño de página? Análisis de formularios El analisis de formularios consiste en considerar el numero de veces que los usuarios dejan de rellenar un formulario en un tema concreto. Por ejemplo, una web para la que trabajé descubrió que, en el formulario de introducción de los datos de la tarjeta de crédito, un 0,2% de los usuarios dejaban de rellenar el formulario en el momento en que se les pedía marcar la casilla para suscribirse al newsletter de la empresa. No era obligatorio, pero lo parecía, y lo más gravisimo es que los usuarios ya habían introducido los datos de su tarjeta de crédito (es decir, habíamos logrado convencerlos para comprar), y sin embargo abandonaban. Es muy dificil detectar este tipo de cosas en un test de usuarios, ya que que afectan a un porcentaje de usuarios muy chico (a pesar de que en el ejemplo anterior, un 0.2% significaba una media de 3 compras menos por dia, es decir unos 6000 euros al mes, porción nada despreciable!) Asi mismo, el analisis de formularios faculta detectar fallos en: el vocabulario que utilizamos para definir ciertos campos las validaciones automaticas de los campos (que a veces no son validas para todos los paises, por ejemplo el formato del NIF o la extensión de un numero de telefono) los campos innecesarios o que incomodan al usuario, etc. Rutas de navegación Los reportes de "clickstream" son quizas el fundamento mas potente de dispositivos de analitica web avanzada como Omniture SiteCatalyst o Visual Sciences. Faculta contestar a preguntas como por ejemplo: ¿Por qué páginas navegan los usuarios, y en qué orden? ¿Qué páginas visitan los usuarios dadas una página inicial y una página final determinadas? ¿En cada paso de un proceso de compra o de registro, cuantos usuarios pasan al próximo paso, cuantos vuelven al paso previo o cuantos abandonan? ¿Los que abandonan, a donde van? ¿Qué rutas llevan a una página determinada? ¿Cuáles son las 5 rutas que realizan el 90% de los usuarios de mi sitio web? Ejemplo de reporte de rutas de navegación de Omniture SiteCatalyst Estos reportes son muy utiles para considerar que realizan los usuarios en vuestro sitio web y, quizas mas significativo todavia, que no son capaces de hacer (seguramente debido a que la pagina no es usable). Así mismo, nos ayudan a definir la arquitectura de la información y el esquema de navegación del sitio web basándonos en la experiencia y preferencias de navegación de los usuarios. Otras técnicas de analítica web Tienen lugar muchas otras tecnicas de analitica web que nos facultan mejorar la usabilidad de un sitio web. A continuacion menciono algunas, que en otros productos comentare en detalle: Análisis de "bounce rate" Analisis de frutos de busqueda Segmentación de tascas y usuarios Satisfacción de los usuarios Especialmente significativo es la segmentacion de tascas y usuarios, que faculta agrupar a los usuarios segun las tascas que realizan en el sitio web, para luego ofrecer contenidos e interfaces adaptados a cada perfil.

La usabilidad de los sitios en Internet esta alguna porque los contenidos y los servicios que brindan sean de sencillo comprension y entrada por fracción de los usuarios. El éxito de un sitio está relacionado directamente con su probabilidad de uso, por lo que garantizar su usabilidad debe liderar la lista de consideraciones previas al diseñar en Internet. La arquitectura de la inmaneracion se descubre intimamente ligada con la usabilidad, ya que decide la manera en la cual se estructuran los contenidos y dispositivos que conmaneran el sitio (barras de navegacion, motores de busqueda, sistemas de etiquetas, inmaneracion en general, la manera de hacer transacciones de comercio electronico, entre otras cosas). Una arquitectura de inmaneracion bien proyectada clarifica la mision y vision del sitio, equilibrando las necesidades del cliente y los usuarios; asi como tambien contribuye a que el usuario tenga una experiencia de navegacion satisfactoria. Con el fin de decidir la arquitectura de la informacion a implementar se debe construir un proceso de investigacion anterior que comprende algúnas etapas o pasos: Análisis de la industria Determinación de la audiencia Estudios de la competencia Ideas iniciales sobre el sitio Todas estas actividades estan dirigidas a estructurar el sitio y a definir sus funciones principales, metas y tácticas a implementar. Como consecuencia de ese analisis podremos planificar y determinar: Donde estamos, a donde deseamos ir y como haremos para llegar ahi. Al navegar un sitio, el mismo debe proponer una articula clara, que no haya que encontrar y que sea congruente en todas las paginas, que sea familiar y facilite su aprendizaje. Los sitios requieren una buena arquitectura informacional, que permita conocer rapidamente el orden y distribucion de lo que se va a encontrar. El usuario no tiene tiempo para aprender las peculiaridades de un sitio, por lo que es indispensable seguir determinadas normas escenciales de usabilidad. Al llegar a una página el usuario debe reconocer, en primer lugar, dónde está. Debe poder visualizar su posición en la articula global del sitio. Debe poder entender, por la presencia en cada una de las páginas del logo, la coherencia de colores, y la codificación de las jerarquías en los contenidos presentados, que navega por páginas interiores de un mismo sitio. En segundo lugar, debe percibir claramente donde estuvo para eludir repeticiones inutiles, indicando por ejemplo con un color diferente, los enlaces a las paginas ya visitadas. Finalmente, conocer a donde puede ir y cuales son las opciones ofrecidas.

Eludir que se introduzca información incorrecta en un sistema es uno de los requisitos exigidos a la informática desde sus origenes y se ha convertido en una de las funciones mejor implementada por la sencilla razón de que la fiabilidad de un sistema informático depende de la información que contiene. Por ello, la validación establece una función imprescindible en cualquier aplicación informática. Lamentablemente, a menudo, la extrema relevancia que logicamente se otorga a impedir que el sistema se alimente con datos erroneos acaba deteriorando la usabilidad del sistema ya que los programadores se centran solo en controlar en espacio de guiar. En este producto se consideran las caracteristicas de los procesos de validacion de datos de acceso y se ofrecen algunos consejos para mejorar la usabilidad del sistema. Tipos de validaciones Las verificaciones a aplicar sobre la información a introducir en un sistema pueden analizarse aplicando distintos puntos de vista. A. Según el momento en el que se realicen Una misma validacion, como verificar que el valor introducido en un tema de fecha es correcto, puede llevarse a cabo en dos momentos distintos: justo al acabar de advertir el tema con lo cual estaremos ante una validacion a nivel de tema, o bien al requerir que se introduzca toda la informacion del formulario de entrada, es decir, al darle al ?OK?, con lo cual estaremos ante una validacion a nivel de formulario. Escoger entre estos dos momentos para efectuar una validacion concreta entabla un discusion entre dos puntos de vista antagonicos: por un lado, el que defiende que el sistema debe controlar al usuario, y por el otro, el que opina que es el usuario quien debe tener el control sobre el sistema. Bruce Tognazzini estima esta segunda perspectiva como una caracteristica necesaria para lograr una interfaz de usuario efectiva. Por este motivo, se recomienda que, como regla general, las validaciones se apliquen a nivel de formulario ya que ello faculta que el usuario ?navegue? libremente por los campos del formulario sin que el sistema le interrumpa constantemente mostrandole mensajes de yerro por no superar una validacion a nivel de campo. Seguir esta recomendacion permitira conocer, entre otras informaciones, el contenido de los valores de las combo-boxes y favorecera que el usuario se forme un mejor modelo mental de la aplicacion. Además, conviene indicar que, si bien el contenido de un tema puede verificarse tanto a nivel de tema como a nivel de formulario, determinados tipos de validaciones sólo pueden efectuarse a nivel de formulario. Entre otras, aquellas que comprueban: informacion que no se descubre explicitamente en ningun tema del formulario, como, por ejemplo, el nivel de autorizacion del usuario que esta precisamente introduciendo datos en el formulario; estados que sólo se producen al dar ?OK? al formulario de entrada, como, por ejemplo, verificar, en un proceso de búsqueda, que el usuario ha informado un número mínimo de filtros a aplicar. B. Según el objeto sobre el que se apliquen Atendiendo al objeto a verificar, una validación puede ser: Simple: cuando explora el contenido de un solo campo, o bien Compuesta: cuando explora el contenido de un tema en relación al contenido de otro u otros temas ya informados en el formulario. En el caso de validaciones compuestas resulta todavía más recomendable, si cabe, realizarlas a nivel de formulario para permitir que el usuario esté al tanto de las variadas mezclas de valores disponibles antes de darle al ?OK?. Para ello, la habilitación/deshabilitación dinámica de campos y controles resulta de mayor ayuda. C. Según el tipo de característica que validen Cualquiera de las informaciones que gestiona todo sistema se inscribe en una de estas dos categorías: Aquello que manera fraccion del conocimiento del usuario, bien sea porque pertenece al mundo real, como, por ejemplo, que las personas se clasifican en mujeres y hombres; bien sea porque se descubre en su cabeza, como, por ejemplo, que una persona se identifica por su nombre y apellidos. Aquello que el usuario desconoce. Y que, a menudo, manera fraccion de la propia logica de la aplicacion, como, por ejemplo, que las fechas deben inmanerarse con 4 digitos para el año o que para dar de alta un nuevo cliente el usuario debe poseer un nivel de autorizacion sobresaliente a X. Aunque es cierto que, a medida que el usuario va interaccionando con el sistema, su modelo mental del mismo sera mas completo y, en consecuencia, determinados componentes de la logica de la aplicacion pasaran a formar fraccion del conocimiento del usuario; resulta evidente que el tipo de conocimiento al que pertenezca la caracteristica a cerciorar afectara directamente a la facilidad de comprension del usuario. No es lo mismo verificar que en un tema de importe se introducen solo numeros, que cerciorar que en un servicio de reserva de accesos a espectaculos no se soliciten mas de 6 accesos o que la compra se realice con una antelacion minima de 3 dias sobre la fecha celebracion. En este caso, resulta imprescindible un tratamiento excelente de los mensajes del sistema tanto en su redaccion como en elegir el tipo de mensaje correcto para que el usuario llegue a conocer las peculiaridades del sistema que esta usando y logre su objetivo. Validaciones sobre el formato de un dato Son las tipicas comprobaciones sobre la conmaneracion y el dimension del valor introducido en un tema, como, por ejemplo, que solo sean numeros o mayusculas, o que una fecha siga el patron ?DD-MM-AA?. Manteniendo la preferencia por las validaciones a nivel de formulario, en estos casos, resulta un escaso mas admisible aplicar una validacion a nivel de tema. A pesar de ello; la mejor solucion consiste en que sea el propio sistema quien, proactivamente y de manera automatica, realice las acciones necesarias para dejar el valor en el manerato correcto, como, por ejemplo, introduciendolo en mayusculas aunque el usuario este tecleando minusculas o manerateando los separadores de las fechas con el caracter previsto por el sistema al dejar el tema correspondiente. Orden de las validaciones Otro agente que afecta a la usabilidad es el orden con que se aplican las validaciones a nivel de formulario. Por ejemplo, resulta muy molesto que: al darle al ?OK? a un formulario la primera validacion genere un mensaje de yerro señalando que el tema A es obligatorio y que no se ha informado; que el usuario informe el tema A y al darle otra vez al ?OK? el sistema le indique que el valor con que se ha informado el tema A no es correcto; que el usuario modifique el contenido del tema A y al darle otra vez al ?OK? el sistema le informe, justo ahora, que no posee el nivel de autorizacion indispensable para contratar este formulario de entrada. La sensación de frustración y de pérdida de tiempo que provoca en el usuario es del todo innecesaria y puede resolverse muy fácilmente si las validaciones se ejecutan siguiendo un orden lógico como, por ejemplo el siguiente: Confirmar que la aplicacion esta disponible ya que si no esta operativa no tiene sentido verificar ningun dato del formulario de entrada. Comprobar que el usuario está autorizado utilizar el formulario de entrada. Comprobar, uno a uno, que están informados todos los campos obligatorios. Estas validaciones se realizarán considerando, para cada campo, las verificaciones A y B que se describen a continuación: Si el formulario de acceso sirve para crear una nueva ocurrencia de un objeto, asegurar que esta ocurrencia efectivamente no tiene lugar en la fundamento de datos. Si, por el contrario, el formulario de acceso sirve para consultar, adaptar o descartar una ocurrencia; confirmar que esta si tiene lugar en la fundamento de datos. Esta validacion hay que ejecutarla inmediatamente luego de haberse superado el paso numero 2 sobre el tema que contiene el valor de la ocurrencia. Ejecutar las validaciones compuestas, aquellas que consideran el contenido de un tema en relacion al contenido de otro u otros temas ya informados en el formulario. Cerciorar el resto de campos Ademas, en el orden de ejecucion de las validaciones hay que seguir la secuencia de izquierda a derecha y de encima bajo considerando las agrupaciones de campos que tenga el formulario. Es decir, seguir el mismo orden que se aplique al desplazamiento del foco de teclado entre campos que explica Josep Casanovas en su producto ?Diseño de formularios - Campos (II). Implementar las menos validaciones probables Nadie discute la necesidad de controlar el contenido de un formulario de entrada, pero un diseño inteligente puede reducir mucho el numero de validaciones a aplicar y esto, asimismo de favorecer la usabilidad porque el usuario va a padecer menos interrupciones, tambien puede favorecer un menor coste de desarrollo, pruebas y mantenimiento. A continuación se indican varios recursos, algunos de los cuales ya menciona Josep Casanovas en su artículo, para reducir el número de validaciones a realizar: Usar temas con listas de valores asociadas o combo-boxes que facilitan que el usuario informe el tema con un valor correcto. Advertir los temas con un valor por defecto. Éste debe ser el mas probable. En caso que no convenga advertir con un valor por defecto, indicar dentro del propio tema las caracteristicas de los valores correctos. Agregar un chico texto explicando el formato y/o rango de valores correcto. Habilitar/deshabilitar dinámicamente campos y/o botones según el estado del formulario, el perfil del usuario o cualquier otra circunstancia. Convertir automáticamente el contenido de un tema al formato correcto. Agregar acciones especificas para asignar valor a un campo, como, por ejemplo, agregar un almanaque para introducir una fecha. Aunque es totalmente imprescindible verificar la informacion a introducir en un sistema, cuando las validaciones se aplican con un orden logico y se reducen al maximo, el usuario las percibira como una ayuda en espacio de como un obstaculo, mejorando la usabilidad del sistema.