Programación java

1. definicion del asunto Lo primero que hay que realizar es definir el asunto en su conjunto. ?Muchos diseñadores creen que los asuntos ya han sido suficientemente definidos por sus clientes. Pero esto no es en absoluto suficiente?, dice Archer. Por tanto es indispensable iniciar por la definicion del problema, que servira tambien para definir los limites en los que debera moverse el proyectista. Supongamos que el asunto consiste en proyectar una lampara, habra que definir si se trata de una lampara de sobremesa o de aplique, de analizó o de trabajo, para una sala o un dormitorio. Si esta lampara tendra que ser de incandescencia o fluorescente o de luz diurna o de otra cosa. Si tiene que tener un precio limite, si va a ser distribuida en los masivos almacenes, si debera ser desmontable o plegable, si debera llevar un reostato para regular la intensidad luminosa, y cosas por el estilo. 2. fundamentos del asunto Cualquier asunto puede ser descompuesto en sus elementos. Esta operacion facilita la proyectacion porque tiende a encontrar los pequeños asuntos propias que se ocultan tras los subasuntos. Una vez resueltos los pequeños asuntos de uno en uno (y aqui empieza a intervenir la creatividad abandonando la idea de buscar una idea), se recomponen de manera coherente a dividir de todas las caracteristicas funcionales de cada una de las fracciones y funcionales entre si, a dividir de las caracteristicas materiales, psicologicas, ergonomicas, estructurales, economicas y, por ultimo, manerales. "Lo bello es la consecuencia de lo correcto", Rezad una norma japonesa. El comienzo de descomponer un asunto en sus fundamentos para poder analizarlo procede del metodo cartesiano. Como los asuntos, sobre todo hoy en dia, se han convertido en muy complejos y a veces en complicados, es indispensable que el proyectista tenga toda una serie de informaciones sobre cada asunto propia para poder proyectar con gran seguridad. Tal vez sea oportuna una definicion de "complejidad" para poder diferenciar lo complejo de lo complicado. Para Abraham A. Moles "un articulo es complicado cuando los fundamentos que lo componen pertenecen a numerosas clases diferentes; entretanto que es complejo si contiene un mayor numero de fundamentos reagrupables no obstante en pocas clases". Podria decirse que un automovil es complicado entretanto que un ordenador electronico es complejo. Actualmente se tiende a la produccion de objetos escaso complicados, a reducir el numero de las clases de los fundamentos que forman un producto. Asi pues, en un futuro habra cada vez menos artículos complicados. Descomponer el asunto en sus fundamentos desea decir encontrar numerosos subasuntos. "Un asunto propia de diseño es un conjunto de muchos subasuntos. Cada uno de ellos puede resolverse obteniendo un tema de soluciones aceptables", asevera Archer. Cada subproblema tiene una solucion optima que no obstante puede estar en contradiccion con las demas. La fracción mas ardua del esfuerzo del diseñador sera la de conciliar las distintos soluciones con el programa global. La solucion del asunto común consiste en la coordinacion creativa de las soluciones de los subasuntos. Supongamos que el asunto presentado sea el de proyectar una lampara y supongamos tambien haber definido que se trata de una lampara de luz diurna para una habitacion normal. Los subproblemas son: Qué tipo de luz deberá tener esta lámpara. Si esta luz deberá estar graduada por un reóstato. Con qué material habrá que construirla. Con que tecnologia habra que laborar este material para realizar la lampara. Dónde tendrá el interruptor. Cómo será transportada, con qué embalaje. Cómo se dispondrá en el almacén. Si hay fracciónes ya prefabricadas (portalamparas, reostato, interruptor, etc.). Qué manera tendrá. Cuánto deberá costar. Estos son los subproblemas que hay que resolver en manera creativa. 3. recopilación de datos Sigamos todavia con el ejemplo del programa de la lampara y veamos que datos convendra recoger para determinar despues los fundamentos constitutivos del programa. En primer espacio el diseñador tendra que recoger todos los catalogos de las fabricas que producen lamparas similares a la que hay que proyectar. Es evidente que, antes de pensar en cualquier probable solucion, es mejor documentarse. No vaya a ser que alguien se nos haya adelantado. Carece completamente de sentido ponerse a pensar en un tipo de solucion sin saber si la lampara en la que estamos trabajando ya tiene lugar en el mercado. Por supuesto se encontraran muchos ejemplos que habra que eliminar pero al final, eliminando los duplicados y los tipos que jamás podran ser competitivos, tendremos una buena recopilacion de datos. Despues para cada fundamento del problema, tendremos que buscar una vez más mas datos: Cuantos tipos de bombillas tienen lugar actualmente en el mercado. Cuántos tipos de reóstatos. Cuántos tipos de interruptores. Etcétera. 4. análisis de datos El analisis de todos los datos recogidos puede proporcionar sugerencias sobre que es lo que no hay que realizar para proyectar bien una lampara, y puede orientar la proyectacion hacia otros materiales, otras tecnologias, otros costes. 5. creatividad La creatividad reemplazara a la idea intuitiva, vinculada todavia a la manera artistico-romantica de resolver un problema. Asi pues, la creatividad ocupa el espacio de la idea y procede segun su metodo. Entretanto la idea, vinculada a la fantasia, puede proponer soluciones irrealizables por razones tecnicas, materiales o economicas, la creatividad se mantiene en los limites del problema, limites derivados del analisis de los datos y de los subproblemas. 6. materiales - tecnologías La sucesiva operacion consiste en otra pequeña recogida de datos relativos a los materiales y a las tecnologias que el diseñador tiene a su disposicion en aquel momento para hacer su proyecto. La industria que ha planteado el asunto al diseñador dispondra verdaderamente de una tecnologia particular para fabricar determinados materiales y no otros. Por tanto es inutil pensar en soluciones al borde de estos dos datos relativos a los materiales y a las tecnologias. 7. experimentación Es ahora cuando el proyectista hacera una experimentacion de los materiales y las tecnicas disponibles para hacer su proyecto. Muy a menudo materiales y tecnicas son utilizados de una unica manera o de muy pocas maneras segun la tradicion. Muchos industriales dicen: ?Siempre lo hemos hecho asi, ¿por que habria que cambiar??. En cambio la experimentacion faculta encontrar nuevos usos de un material o de un instrumento. Hace algunos años fuese lanzado al mercado un articulo industrial llamado Fibralin, compuesto de fibras de rayon entretejidas como un fieltro, de goma sintetica. Este material habia sido producido para sustituir a determinados tejidos utilizados en la confeccion en el interior de las prendas y se fabrica en distintos grosores, desde el del papel de fumar al del carton. Tenia un precio muy asequible y un apariencia agradable semejante al papel de seda japones. Este material, que todavia se produce, resiste bien la impresion serigrafica, y yo mismo hice algunas pruebas con el. Con este material proyecte instalaciones efimeras para exposiciones de articulos industriales. Desde entonces ese material, inventado para la confeccion, es utilizado por sus cualidades y probabilidades especificas, inclusive en instalaciones y en impresiones artisticas en serigrafia. 8. modelos Estas experimentaciones facultan extraer muestras, pruebas, informaciones, que pueden llevar a la construccion de modelos demostrativos de nuevos usos para determinados objetivos. Estos nuevos usos pueden ayudar a resolver subproblemas parciales que a su vez, junto con los demas, contribuiran a la solucion global. Como se desprende de este esquema de metodo, todavia no hemos hecho ningun dibujo, ningun boceto, nada que pueda definir la solucion. Todavia no conocemos que manera tendra lo que hay que proyectar. Pero en cambio poseemos la seguridad de que el borde de probables errores sera muy reducido. Ahora podemos iniciar a establecer vinculos entre los datos recogidos e intentar aglutinar los subproblemas y realizar determinado boceto para desarrollar modelos parciales. Estos bocetos hechos a escala o a dimensión natural pueden mostrarnos soluciones parciales de englobamiento de dos o mas subproblemas. De esta manera obtendremos un modelo de lo que eventualmente podrá ser la solución del problema. 9. verificación Este es el momento de llevar a cabo una verificacion del modelo o de los modelos (puede ocurrir que las soluciones probables sean mas de una). Se muestra el modelo a un algun numero de probables usuarios y se les pide que emitan un juicio sincero sobre el objeto en cuestion. Sobre la fundamento de estos juicios se realiza un control del modelo para ver si es probable modificarlo, siempre que las observaciones posean un valor objetivo. En fundamento a todos estos datos ulteriores se pueden iniciar a preparar los dibujos constructivos a escala o a dimensión natural, con todas las medidas exactas y todas las indicaciones necesarias para la realizacion del prototipo. bocetos Los dibujos constructivos tendrán que servir para comunicar a una persona que no esté al corriente de vuestros programas todas las informaciones útiles para preparar un prototipo. El esquema del método de proyectación, ilustrado en páginas precedentes, no es un esquema fijo, no está completo y no es único y definitivo. Es lo que la experiencia nos ha dictado hasta ahora. Insistimos sin embargo en que, a pesar de tratarse de un esquema flexible, es mejor proceder, de momento, a las operaciones indicadas en el orden presentado: idéntico que en la proyectación del arroz verde (ver más abajo) no puede ponerse la cazuela al fuego sin el agua ni preparar el condimento una vez cocido el arroz. No obstante, si hay alguien capaz de demostrar objetivamente que es mejor cambiar el orden de cierta operacion, el diseñador esta siempre dispuesto a adaptar su pensamiento frente a la evidencia objetiva, y es asi como cada uno puede aportar su contribucion creativa a la estructuracion de un metodo de esfuerzo que tiende, como es sabido, a conseguir el maximo fruto con el minimo esfuerzo. Ejemplo:Problema arroz verde Definicion del asunto arroz verde con espinacas para cuatro personas Fundamentos del asunto arroz, espinacas, jamon, cebolla, aceite, sal, pimienta, caldo Recopilación de datos ¿hay alguien que lo haya hecho antes? Análisis de datos ¿cómo lo ha hecho? ¿qué puedo aprender de él? Creatividad ¿cómo puede conjugarse todo esto de una manera correcta? Materiales Tecnología ¿qué arroz? ¿qué cazuela? ¿qué fuego? Experimentación pruebas, ensayos Modelos presenta definitiva Verificación bien, vale para 4 Dibujos Constructivos ? Solución Arroz Verde servido en plato cálido

Los formularios son usados para comprar, registrarse, buscar, suscribirse, asociarse, etc. todos ellos procesos basicos para la supervivencia de un sitio web y su eslabon mas fragil. Cuando un usuario se determina a completar un formulario ya ha tomado una decision (compra, suscripcion, registro, etc.) y esta dispuesto a llevarla a cabo, el sitio web ha tenido exito y solo falta "rematar la faena". Entre la intencion del usuario y una cumplimentacion exitosa el agente mas significativo es la usabilidad. De ella dependera su ratio de cumplimentacion, es decir, el cociente entre el numero de usuarios que finalizan el formulario y numero total de usuarios que lo comienzan. Radio buttons: Se emplean para restringir la respuesta a una pregunta a unas algunas alternativas de respuesta, de las cuales solo es probable elegir una. En algunos casos esto se hace porque realmente solo es probable una respuesta, por ejemplo, "sexo: hombre o mujer". Pero en otros tambien se usa para realizar al usuario decantarse por la alternativa preferida o mas cercana, en estos caso las alternativas han de ser mas cuidadas para no abandonar afuera ninguna probable respuesta. En el pronunciado de la pregunta es significativo que quede diafano que se trata de optar entre las respuestas. Las alternativas han de ser redactadas de tal forma que forzosamente cierta de ellas satisfaga al usuario. Han de ser claramente excluyentes entre ellas y no ha de tener sentido responder dos al mismo tiempo. En caso de que haya duda y que sea probable que ninguna de las respuestas sea adecuada, se ha de incluir una alternativa tipo "No aplicable", "Otros" o "No sabe/no contesta". En cualquier caso, si se llega a esta situacion es recomendable revisar la pregunta y las alternativas, ya que que esta duda suele ser indicador de una inadecuada redaccion. La redaccion de las respuestas es primordial porque muchos usuarios no leen el pronunciado de la pregunta y solo lo infieren del conjunto de respuestas posibles. La comprension de que hay que optar entre las respuestas se logra mediante la cercania espacial de los radio buttons como se puede ver en el próximo ejemplo: Generalmente si las probables respuestas son largas y mas de dos, es mejor la alineacion vertical. Aunque si la respuesta tiene solo dos posibilidades, tipo "sexo", se puede optar tambien por presentarlas en horizontal, para ocupar menos espacio. Lo que jamas se debe realizar es insertar algunas lineas de texto o lugares entre los radio buttons porque las probables alternativas quedan demasiado lejos unas de otras, no queda diafano en un vistazo veloz que se ha de elegir solo una y obliga a leer atentamente los textos. Vease el ejemplo de uso inadecuado: Ademas si se selecciona una alternativa por defecto, esta debe ser la primera en el orden y la mas comun. El numero maximo de alternativas fluctua dependiendo de su extension y complejidad. Si las alternativas son cortas y sencillas, hasta un maximo de cinco seria aceptable. Sin embargo, si las alternativas son largas y de ideas complejas un numero gran de 3 disminuiria mucho su usabilidad. En estos casos es recomendable partir la pregunta compleja en dos mas simples. Combos: Los combos se emplean para restringir la respuesta de una pregunta a unas algunas alternativas de respuesta, de las cuales solo es probable elegir una. En verdad son muy parecidos a los radios buttons, pero su uso es algo distinto. La mayor diferencia es que las respuestas de los combos estan ocultas para ocupar menos lugar en el formulario. Sin embargo para que los combos sean usables deben contener alternativas mas simples que en los radio-buttons. Estas alternativas han de ser completamente predecibles, sencillas e inequivocas tras leer el pronunciado de la pregunta. Un ejemplo correcto seria "nivel de estudios: EGB, FP, Universidad". Si se ha de desplegar el combo para entender las alternativas contenidas en un combo, no se cumple el comienzo de la visibilidad. En este ejemplo hasta que no se despliega este combo: no se pueden entender las alternativas contenidas en el: Como hemos comentado anteriormente, muchos usuarios ni siquiera leen el pronunciado de las preguntas, sino que se limitan a elegir una respuesta de entre las probables. Si las alternativas de los combos no son predecibles o sencillas, este proceso de eleccion y comparacion entre probables respuestas se dificulta mucho. Los combos se emplean para eludir errores en la introduccion de informacion, pero en ese sentido solo se deben utilizar cuando la relevancia de la correccion de los datos sea tan apreciacion que obligue a ello. No es razonable utilizar combos indiscriminadamente y para alternativas innecesarias u otras demasiado largas. Por ejemplo, si en el combo "pais" se incluyen todos los paises del mundo se hace muy dificil de utilizar. El usuario escribe antes el nombre del pais manualmente que seleccionandolo en un combo de mas de 100 alternativas. Asimismo "pais" en la mayoria de los casos no es un tema critico y su ratio de errores muy bajo. Check-boxes: Los check-boxes se emplean en dos casos: 1) Para restringir la respuesta de una pregunta a unas algunas alternativas de las cuales es probable elegir varias. En este caso se suelen utilizar para recoger información de los usuarios acerca de preferencias, gustos o cualquier otro tipo de pregunta que requiera una respuesta múltiple y variada. 2) Para mostrar una unica alternativa que no es obligatoria. Por ejemplo, confirmar la lectura de condiciones de contratos, optar por recibir correos electronicos con publicidad, etc. Para que se produzca una confirmacion real y consciente del usuario, la check-box debera surgir por defecto sin marcar, en caso opuesto el usuario puede perder confianza en el sitio e interpretar su politica como engañosa. En este ejemplo del registro para el correo de Yahoo podemos ver ambos usos, aunque en el primero optan por marcar por defecto la alternativa de recibir publicidad. Campos de texto: Se emplean cuando se desea permitir cualquier tipo de respuesta a una pregunta del formulario. Son los preferidos por los usuarios que saben que pueden escribir casi cualquier cosa. La extension del tema es significativo porque da a los usuarios la clave sobre la extension de la respuesta esperada, ello les hace ajustarla y entender mejor la pregunta. Por ejemplo, pueden deducir que si su respuesta ocupa mas lugar del disponible seguramente no sea la adecuada. En la direccion postal (tipo de via, nombre de la via, numero, piso, escalera, puerta, etc.) es adecuado un solo tema de texto. Un usuario requiere menos tiempo para completar un unico tema, porque lo hace muy frecuentemente y no es sencillo que cometa errores. En algunos casos la excesiva separacion de los datos en distintos temas provoca errores porque no es probable incluir plenamente todos los probables fundamentos de la direccion (piso, escalera, puerta, bloque, escalera, patio, etc.), lo que puede confundir al usuario y originarle una falta de confianza en el adecuado fruto del proceso. Siendo la direccion postal un tema que no se explora en la fundamento de datos y simplemente se imprime en las etiquetas de los sobres, no tiene sentido utilizar 4 o 5 temas distintos para su recogida (en caso de necesidad se puede usar el codigo postal que se recoge en un tema distinto). La fecha es uno de los campos de texto que más errores genera en la mayoría de los formularios. Casi siempre incluye un ejemplo de formato o necesita de usar combos muy incómodos no justificados para un dato tan sencillo. El formato más correcto para la mayoría de los casos es este: Una validación de errores paciente con la falta de ceros a la izquierda y que también acepte solo dos dígitos en el año permitirá un funcionamiento adecuado. Un yerro tipico es introducir el salto automatico entre temas de texto consecutivos y realizar inindispensable el uso del tabulador. Aunque este comportamiento puede parecer que facilita la tarea de introduccion de datos, no es correcto porque quita control a los usuarios, no es un funcionamiento estandar y es indispensable contemplar la pantalla para saber en que tema se esta. Todo ello puede provocar facilmente yerroes, como por ejemplo, introducir datos pertenecientes a un tema en el próximo cuando no se introduce el formato esperado por el salto automatico. En la validación de campos de texto, se recomienda aceptar algunos "errores" comunes como lugares en los números de teléfono, los puntos de millares o el uso indistinto de mayúsculas o minúsculas. Recomendaciones generales: Para eludir la incomodidad del cambio entre teclado y raton, es recomendable, cuando tenga sentido, agrupar por un lado los controles que se manejan con el raton (radio-buttons, check-boxes, combos) y por otro los que se manejan con el teclado (campos de texto), en espacio de alternarlos. Respecto a la situación, tanto los "radio button" como los "check-box" siempre se han situar a la izquierda de la etiqueta del campo, así se favorece la alineación vertical de todos los controles. Por el opuesto los combos y los campos de texto deben situarse a la derecha de la etiqueta del campo.

Las etiquetas son los textos que detallan cada objeto o grupo de objetos que forman fracción de un formulario. Por lo tanto siempre van asociadas a otros elementos, los cuales reciben el nombre de controles. Las etiquetas ayudan al usuario a comprender la funcion cada control del formulario. Entre otras cosas detallan el contenido de los campos y dan nombre a los valores de las casillas de verificacion (checkboxes) y de los botones de alternativa (radiobuttons). Tipografía Se recomienda usar tipos de letra sin serifa, es decir sin remates, como son los tipos Verdana, Arial y Tahoma. Esta recomendación sirve también para cualquier texto que aparezca en una pantalla. El tipo Tahoma es el recomendado por Microsoft en el diseño de aplicaciones GUI en Windows. En el ambito web esta muy desarrollado el tipo Verdana. Redacción Utilizar el lenguaje del usuario. Eludir el lenguaje tecnico o especializado. Debemos investigar cuales son los terminos usados por los usuarios para mencionarse a los conceptos que contiene el formulario y utilizarlos. Por ejemplo, en un ámbito de banca online, términos como "Reintegro", "Imposición" y "Transferencia" podrían ser sustituidos por "Sacar dinero", "Poner dinero" y "Enviar dinero". Ser breve. No usar palabras innecesarias y ubicar el texto en una única línea. Por ejemplo, en un directorio el término "Teléfono móvil", "Dirección de correo electrónico" y "Número de fax" pueden ser sustituidos por "Móvil", "Correo electrónico" y "Fax". Capitalizar la primera palabra. Deberá ir en mayúscula la primera letra de la primera palabra. Esto ayuda a identificar el origen de una etiqueta. En español, a diferencia del ingles, el resto de palabras llevaran la primera letra en minuscula, excepto si son nombre propios. Lo oya que confunde mas que ayuda ya que que no es un uso habitual de vuestro idioma. Palabras clave al inicio. Ubicar al origen de la etiqueta la palabra más significativa. Esto ayuda a la exploración y localización rápida de la etiqueta. Eludir abreviaciones. Seguir las proximos normas cuando sea ineludible usar abreviaciones: Ser consistente: usar la misma abreviación siempre para la misma palabra. Seguir los estándares del usuario, su argot profesional o el de su organización. Por ejemplo: "Cial." por "Comercial" en un ámbito financiero. Cuando no exista ningún estándar para una palabra, se preferirán las abreviaciones por truncamiento: Por ejemplo, "Dir." por "Directorio". En textos largos, puede ser que el truncamiento no sea efectivo, en este caso se podrá usar un acrónimo o crear abreviaciones por compresión. Por ejemplo: "AMEX" por "American Express". Colocar dos puntos al final de la etiqueta. Aunque determinadas guias de estilo indican la opcionalidad de los dos puntos al final de las etiquetas, en mi opinion es preferible usarlos ya que que de esta forma se indica claramente el final del texto de la etiqueta, evitando confusiones con otros textos proximos. Son excepciones a esta norma los textos de los botones de alternativa y de las casillas de verificacion asi como los titulos de los recuadros de grupo. Ubicación Posición A la izquierda del tema o área de texto. Deben situarse preferiblemente a la izquierda del tema, jamas a la derecha ni debajo. Eludir colocar las etiquetas arriba del tema ya que que dificulta su exploracion visual. Cuando sea inevitable, se situaran arriba del tema alineados a la izquierda. Esto es habitual cuando el tema o area de texto ocupa mucho espacio. A la derecha de los botones de alternativa y de las casillas de verificacion. Es significativo seguir esta regla, de lo opuesto el usuario puede confundirse y asociar la etiqueta a otro boton de alternativa o casilla de verificacion. Alineación vertical. Sobre si las etiquetas deben alinearse a la derecha o a la izquierda no hay ningún acuerdo establecido. Tanto un caso como el otro tiene sus ventajas e inconvenientes. Alineación izquierda: Ayuda al escaneo del ojo ya que el origen de todas las etiquetas queda encolumnado y facilita su localizacion rapida, sin embargo tiene como inconveniente que determinadas etiquetas pueden quedar excesivamente separadas de su tema o control. Alineación derecha: Lo que para la alineación izquierda es una ventaja, aquí se convierte en un inconveniente y viceversa. Mi táctica preferida: Consiste en alinear las etiquetas a la izquierda excepto cuando, en un grupo, cierta de ellas tenga un texto muy largo. En este caso alineo las etiquetas a la derecha. Alineación horizontal Los textos de las etiquetas y de los campos deben estar alineados horizontalmente bebiendo como referencia la linea fundamento del cuerpo del texto. Separación con el tema o control: Si se adopta la alineación derecha, todas las etiquetas tendrán la misma separación de su tema o control. La distancia de separación no debe ser jamás excesiva. Una separación aproximada de 12 píxeles será suficiente. Si se adopta la alineación izquierda, se tomará como referencia una separación aproximada de 12 píxeles desde la etiqueta más larga hasta su tema o control. El resto de etiquetas se alinearán en referencia a esta. Estados La etiqueta debe reflejar el estado del tema o control al que esta asociado. Por ejemplo, si un tema, casilla de verificacion o boton de alternativa no esta no disponible, su etiqueta tambien lo mostrara. Interacciones En las etiquetas de las casillas de verificación y de los botones de opción, el texto debe ser clicable y activar la misma acción de su control asociado.

¿Un sistema de proceso transaccional puede realmente llegar a disponer de una interfaz de usuario enfocada a la interacción objeto-acción? Yo mismo respondia afirmativamente a esta pregunta en mi ultimo articulo, aunque dejaba diafano que la solucion necesita un cambio de arquitectura tecnologica. Sostengo que la tecnologia dominante en los sistemas de proceso transaccional fuerza a crear interfaces de usuario con el modelo de interaccion accion-objeto que conlleva una serie de dificultades de usabilidad. En el presente articulo hago una propuesta de arquitectura transaccional enfocada a dar soporte a una interfaz de usuario objeto-accion. Para ello parto del analisis del modelo mental del usuario en interfaces de ambitos transaccionales, describo los fundamentos basicos de la nueva interfaz objeto-accion y, finalmente, propongo la arquitectura tecnologica necesaria para realizar viable esta interfaz. Modelo mental del usuario Para conducir un coche no necesitamos un mayor conocimiento de su ingeniería, nos basta con saber que tiene un motor que lo empuja y que, de vez en cuando, hay que ponerle gasolina. Igualmente, cuando compramos un libro en Amazon, basta con saber que detrás del cable que nos conecta a la red hay un ordenador central que recogerá vuestro pedido y que sólo lo procesará si introducimos un número de tarjeta de crédito. Las personas nos formamos una idea de cómo son y cómo funcionan los sistemas cuando interactuamos con ellos, ya sean ordenadores u otros aparatos. No se trata de una imagen exacta de la realidad, tan sólo es una idea imprecisa que nos ayuda a hacerlos funcionar. Esta idea mental recibe el nombre de ?modelo mental del usuario?. Donald Norman lo explica con detalle en su libro La psicología de los objetos cotidianos. Modelo mental del usuario en interfaces clásicas de sistemas de proceso transaccional Los modelos mentales para interfaces WIMP (windows, icons, menus pop-up and pointer) y para interfaces Web han sido muy estudiados (consultar el interesante articulo de Dick Berry). En cambio, es muy dificil descubrir estudios que hablen del modelo mental en las interfaces implantadas en sistemas de proceso transaccional. El modelo mental del usuario para estas interfaces se puede describir de la próximo manera: 1.Elementos que lo componen: Terminal con pantallas que contienen botones, alternativas de menu y formularios con etiquetas y campos para introducir datos. Ordenador central remoto que procesa la información. Esta idea de ordenador distante establece un concepto muy potente dentro de la mente del usuario. Información que viaja por la red con los datos que envía el terminal hacia el ordenador central. Respuestas del ordenador central hacia el terminal, usualmente en manera de texto. 2.Espacio: Lugar afuera del control del usuario. Para el, los datos estan en un lugar inaccesible. Lugar finito limitado por una temática concreta: libros, viajes, mercado de valores, etc. Propietario identificado a quien poder reclamar, que protege la información. El usuario percibe independencia entre su interfaz (PC, web, movil, etc.) y el ordenador central, lo cual le faculta mantener el mismo modelo mental aunquelal interfaz sea distinto en cada canal. 3.Formas de presentación: El usuario percibe que las maneras de presentación son distintos dependiendo del canal en el que esté operando: autoservicio, móvil, web, terminal financiero, etc ... 4.Navegación: El usuario tiene la sensacion de que la navegacion esta totalmente guiada, ya que no dispone de ninguna alternativa para cambiar el flujo del dialogo. El usuario, en funcion del canal donde este operando, puede descubrirse con sdeterminados de los próximos sistemas de navegacion: a)Navegación por menús. b)Diálogo guiado paso a paso, muy propio de terminales de autoservicio y ámbitos web. 5.Interacción: Percepcion de conexion y desconexion: el usuario tiene la sensacion de que, desde el momento en que envia la informacion hasta que recibe la respuesta, hay un tiempo de conexion mientras el cual cede el control al ordenador central. El usuario interactúa con la interfaz dentro de unidades de esfuerzo temporalmente cortas, en las que el meta principal consiste en la introducción de datos a enviar al ordenador central. La interaccion en estas unidades de esfuerzo casi no precisa de mecanismos de interfaz grafica (drag & drop, doble clic, etc.). El usuario solo aguarda poder introducir informacion, seleccionar alternativas y clicar botones de accion. 6.Tiempo de respuesta: Adecuacion al canal: el usuario se adapta al tiempo habitual de respuesta del canal en el que este operando. Por ejemplo, en un formulario web, aceptara un tiempo de respuesta gran que en un terminal de autoservicio. Cambio hacia un modelo mental objeto-acción en interfaces de sistemas de proceso transaccional En el modelo mental del usuario expuesto hasta ahora, no tiene lugar el concepto de objeto manipulable. El usuario sabe que tareas desea hacer y, para ello, debe seleccionar acciones, llenar formularios y enviar informacion a un ?ordenador central? del que aguarda recibir respuestas. Pero si deseamos pasar de un estilo de menus y formularios a un estilo de interaccion objeto-accion, deberemos crear una nueva interfaz con la que el usuario pueda desarrollar un modelo mental que: · Sea coherente con la manipulación de objetos. · Conserve ciertos fundamentos del modelo anterior: ordenador central, conexión y desconexión, etc. · Substituya fundamentos del modelo anterior: unidad de trabajo, navegación por menús, etc. Nuevos apariencias a tener en cuenta para este nuevo interfaz Metaforas: dan al usuario un contexto, un lugar en el que los objetos tienen sentido. Se trata de analogias con el mundo real que ayudan a reconocer los objetos, sus propiedades y su comportamiento. El caso mas clasico de metafora es el del escritorio, utilizado en la gran fracción de sistemas operativos con interfaz grafica: Apple, Windows, etc. Objetos: forman fracción de las metaforas. Deben ser tangibles. En el caso de una sede de venta de libros, por ejemplo, los objetos podrian ser: libro, autor, catalogo? Comportamiento de los objetos. Cada objeto debe tener comportamientos definidos y esperados. Por ejemplo, el objeto ?catálogo?, al abrirse, debe presentar los objetos ?libro? que contiene. Visibilidad de las acciones que el usuario puede realizar sobre cada objeto y tambien visibilidad de las limitaciones que indican lo que no puede realizar. Control del lugar personal. El usuario ha de poder comprender y separar claramente cual es el lugar que controla y cual es el lugar que cede al control del ordenador central. Predictibilidad del alcance de sus acciones. El usuario tiene que poder prever que acciones provocaran una transformación definitiva de los datos y cuales no. Reversibilidad de las acciones. El usuario ha de poder anular facilmente el fruto de sus acciones. Esto es lo que le va a permitir la abierta exploracion y prueba sin miedo a cometer errores irreversibles. Propuesta de cambio de la arquitectura tecnológica La arquitectura tecnologica escencial de un sistema de proceso transaccional se fundamenta en un modelo Cliente-Servidor de dos capas en la que la capa servidora es un sistema remoto y la capa cliente es muy ligera, o sea, casi no tiene capacidad de ejecutar logica de aplicacion. En un modelo transaccional basico, todo el proceso y la gestion del dialogo se ejecuta en la capa servidora. A continuación propongo los cambios y nuevos fundamentos a agregar a esta arquitectura: 1.Control de eventos y ejecución de lógica asociada al modelo de datos en la capa cliente: eso permitirá a la interfaz contener objetos con comportamiento propio. 2.Mantenimiento de contexto de datos con orientación a objetos en una capa intermedia para permitir que el usuario disponga de un lugar controlado por él mismo. 3.Ubicar la lógica de diálogo en una capa intermedia permitiendo que las acciones del usuario no afecten a los datos del servidor. De este modo se ayuda a mejorar la reversibilidad de las acciones del usuario. 4.Hipertransacciones que se traduzcan en grupos de transacciones simples, con el meta de facilitar la actualizacion de los datos del servidor a dividir de los objetos ubicados en la capa intermedia. 5.Traductor del modelo logico de objetos al modelo fisico relacional, situado, posiblemente, en la capa servidora o en una nueva capa intermedia. Este traductor se cimienta en un sistema de equivalencias entre los objetos existentes en la interfaz de usuario y las fundamentos de datos relacionales de los servidores.

Aunque posteriormente se describen todos los frutos y las conclusiones extraidas, a continuacion se presentan las que nos parecen mas relevantes: Se aprecia que falta madurar la multidisciplinaridad de la Interaccion Persona Ordenador (IPO). No se detectan los niveles de multidisciplinaridad que se esperan. Cabe la probabilidad que la encuesta no haya llegado a todos los entornos que se esperaba (psicologia, sociologia, diseño web, etc). Aproximadamente un 60% de los encuestados estan relacionados con la informatica. A pesar de que casi el 60% esta relacionado con la informática, aproximadamente un 30% dijo tener escasos conocimientos en IPO. En el asunto del Diseño Centrado en el Usuario (DCU), encontramos algo muy similar. En este caso, casi el 35% tiene escasos conocimientos sobre DCU. En cuanto a los contenidos, el mas demandado ha sido los ejemplos, lo que de cierta manera prueba que en estos momentos no tienen lugar los suficientes recursos (sitios Web, bibliografia, etc.), que dispongan de ellos. El hacer esta encuesta tambien nos ha ayudado a determinar sobre la incorporación de un lugar de discusion, el cual ha sido aprobado por un alto porcentaje de los encuestados. Mucha gente desarrolla sistemas interactivos, pero profesionalmente, todavía sólo unos escasos de los encuestados tienen la IPO como actividad principal. Tan sólo el 9% de los desarrolladores de sistemas enmarcaron su actividad principal dentro de esta disciplina. Como tecnicas de usabilidad, las mas conocidas han sido las entrevistas y cuestionarios, que no son suficientes para obtener un buen DCU. Las entrevistas y cuestionarios, ayudan a realizar DCU en fases muy concretas, generalmente en fases iniciales, no en todo el proceso. La encuesta realizada, esta estructurada, en cuatro masivos apartados: perfil personal, apariencias relacionados con la informacion de sitio, desarrollo de programas interactivos, y por ultimo conocimiento y uso. Los frutos detallados luego de hacer la encuesta, se presentan siguiendo esta misma division conceptual. A. Perfil Personal Un 74% de los encuestados fueron de sexo masculino, frente al 25% de encuestados de sexo femenino. El 1% restante no respondió. Respecto a la profesion de los encuestados nos encontramos con un notable 40% de estudiantes, 22% de profesorado, tambien 22% de profesionales en desarrollo de sistemas y un 1% de los encuestados no respondieron en cuanto a su profesion. Un 15% de vuestros encuestados afirmaron pertenecer a otros entornos profesionales como documentacion, profesionales de la compañia privada, entendidos en usabilidad, etc. La mayoría de vuestros encuestados, en tangible el 91% tienen entre 20 y 40 años. De los cuales el 59% tienen entre 20 y 30 años, y el 32% entre 31 y 40 años. También es curioso el hecho de que la edad de un 2% sea más de 50 años. Estos datos nos demuestran que la disciplina Interacción Persona Ordenador (IPO) esta creciendo escaso a escaso. Aparte de la profesion, tambien se pregunto sobre el area de conocimiento. La mayoria se ubico en el area de la informatica (41%), seguido por el area de diseño web (21%), la ingenieria (14%), el diseño grafico (7%), la psicologia (3%) y otras areas como sociologia, usabilidad, arquitectura de la informacion, organizacion de compañías e investigacion social, entre otros. No obstante hay que tener en cuenta que un 40% de personas que respondieron la encuesta, son estudiantes, en su mayoria de ingeniería informática, los cuales no tienen todavía un tema de esfuerzo definido más concreto. La encuesta fuese lanzada a través de internet. Principalmente a las listas de distribución de estudiantes y profesores de la Escuela Politécnica Sobresaliente de la Universitat de Lleida, a la de la Asociación Aipo, y las organizaciones Cadius y Aifia. El 81% de las respuestas recibidas procedian de España, aunque también cabe resaltar otros paises, como Alemania, Argentina, Chile, Colombia, Mexico, Perú, EEUU y Venezuela. B. Apariencias relacionados con la información del sitio El 53% de los encuestados se califica con buenos conocimientos en la disciplina de Interaccion Persona Ordenador (IPO) y un 17% son entendidos en felicidad disciplina. Tan solo un 3% de los encuestados dijeron no conocer nada acerca de la IPO. No podemos olvidar el 26% que se califico con escasos conocimientos. En cuanto al Diseño Centrado en el Usuario (DCU), un 44% de los encuestados tiene buenos conocimientos, y el 21% son expertos. En este caso fueron un 4% los encuestados que no conocen nada acerca de este asunto y un 30% dicen tener escasos conocimientos. Acerca de los contenidos que a los encuestados les gustaria descubrir en el sitio web, encontramos bastante igualdad entre las respuestas obtenidas. Los frutos se muestran en la figura 2. Se puede apreciar mediante el grafico de la figura 2, que el gran porcentaje obtenido corresponde al deseo de descubrir ejemplos en el futuro sitio web. Esto nos da pie a suponer, que es algo que los usuarios no encuentran facilmente hoy en dia en los sitios web relacionados con el desarrollo centrado en el usuario. Aunque de todas maneras este porcentaje no es demasiado destacable si lo comparamos con el resto de porcentajes obtenidos. Observamos que un 2% han propuesto otros contenidos o asuntos que les gustaria descubrir en el sitio, como foros de debate especifica, metodologias de diseño centrado en el usuario, experiencias, modelos o pautas a seguir, tanto en usabilidad como en accesibilidad, enlaces y comentarios sobre software, directorio de expertos, cursos, entrevistas... Si analizamos estos datos, en función del perfil de vuestros usuarios, se observa que el porcentaje de demanda de ejemplos más alto es el de los desarrolladores de sistemas (23%). En el profesorado obtenemos un 18% de demanda de ejemplos. Analizando los datos de los estudiantes observamos un empate (19%) entre software y ejemplos, siendo estos su interés principal. El resto de frutos no comentados en propia entre estos tres perfiles de usuarios, es muy similar, y queda ya reflejado en la figura 2. Tambien se pregunto acerca de la creacion de un lugar de discusion. No se pregunto sobre si seria interesante o no que debiera uno, sino en el caso de que se implementara, si los futuros usuarios estarian dispuestos a escribir en el o no. Se han obtenido unos frutos muy favorables. Un 53% de los encuestados respondieron que seguro que si escribirian en el, un 30% contestaron puede ser, y un 12% respondieron no se. Se contemplo tambien, la probabilidad de registrar a los usuarios, con la finalidad de conocerlos. Aunque no se particular esta cuestion, para no condicionar las respuestas. En un comienzo no se ha pensado en ningun momento en restringir el entrada unicamente a usuarios registrados. El 47% ha respondido que seria interesante, un 42% que seria escaso interesante, y un 8% nada interesante. Un 3% no han contestado esta cuestion. Otro apariencia que se ha cuestionado ha sido el tipo de conexion que emplean los encuestados. Esto puede influir en la magnitud de los probables archivos a descargar, ya que ante la probabilidad de una mayoria de usuarios con conexiones lentas, se pudiera observar que los probables archivos a descargar fueron lo mas pequeños probables. En el analisis de los datos se ha obtenido un 59% de conexiones mediante linea ADSL, un 22% de cable, y un 10% de conexiones mediante modem tradicional, un 7% dijeron utilizar otro tipo de conexion (T1, Lan, etc.) y un 2% no conocian la manera en la que acceden a la red. C. Desarrollo de programas interactivos Cuando hablamos de programas interactivos, nos referimos a cualquier tipo de aplicación, ya sea página web, software de escritorio, etc. En el desarrollo de programas interactivos, uno de los puntos significativos es conocer la experiencia en este tipo de programas. A continuacion se presenta un grafico que refleja la experiencia de los encuestados: En la figura 3, observamos que un mayor porcentaje de encuestados tienen más de 3 años de experiencia en programas interactivos, aunque también se observa un porcentaje elevado (20%) de los que no tienen experiencia en este tipo de programas. Otro de los apariencias que se han contemplado es el seguimiento de las premisas escenciales de la IPO (Interaccion Persona Ordenador). En este apariencia se ha obtenido un 73% de respuestas afirmativas. Analizando por perfiles encontramos, que los usuarios que siguen estas premisas basicas, son un 79% en los profesionales en desarrollo de sistemas, seguido de los alumnos (72%), y por ultimo el profesorado (64%). Un 2% y un 3% de encuestados, no contestaron. En referencia al seguimiento de las premisas escenciales del DCU (Diseño Centrado en el Usuario), se ha obtenido un 71% de respuestas afirmativas. Si nos centramos en los perfiles de usuario, encontramos que aquellos que mas siguen las premisas escenciales del DCU son, los profesionales en desarrollo de sistemas (82%), seguidamente los alumnos (70%) y a continuacion el profesorado (55%). En este caso tan solo se obtuvo un 2% de alumnos que no contestaron vuestra cuestion. Profundizando un escaso mas dentro del asunto de desarrollo de programas interactivos, hemos querido saber un escaso mas acerca de la actividad principal de vuestros usuarios. En este punto hemos creido conveniente considerar los frutos por separado. En todos los perfiles los frutos han sido muy igualados entre las actividades principales que se proponian. Pero aun asi cabe resaltar que un 34% de alumnos determinan su actividad principal dentro de la programacion y el area en la que menos alumnos han definido su actividad principal ha sido la IPO (18%). En cuanto al profesorado encontramos una igualdad de frutos entre la IPO, programacion, diseño y analisis. Y finalmente en los desarrolladores de sistemas, destaca el 39% de encuestados que enmarcan su actividad principal dentro del analisis, 28% diseño, 24% programacion y 9% IPO. A continuación detallaremos el tipo de programas interactivos que desarrollan vuestros encuestados. En la figura 4 se reflejan los datos obtenidos: Si de nuevo analizamos los datos por perfiles, encontramos determinadas diferencias. En cuanto al software de escritorio son los alumnos los que mas desarrollan este tipo de programas (28%), frente a los profesores y los desarrolladores de sistemas (9%). En intranets son los desarrolladores de sistemas los que mas laboran en ello (30%). En herramientas interactivos tan solo un 8% de estos, dijeron construir determinado programa de este tipo. Otros tipos de programas en los que se labora son: programas de investigacion, microcontroladores, sistemas de procesamiento masivo de informacion, software cientifico, e-books, software aplicado al control industrial, clustering, software para PDA?s, soluciones tecnologicas, simuladores, investigaciones en moviles, terminales autoservicio, software de investigacion on-line, programas educativos, software para terminales tactiles, etc. Para finalizar el articulo de desarrollo de programas interactivos, se pidio a los encuestados que comentaran si consideraban sus programas sencillos de usar (usables). Se obtuvieron respuestas algo dispares en los comentarios. Algunos se cimientan en pruebas de usabilidad con usuarios para afirmarlo, otros en cambio tan solo expresan su opinion, sin basarla en ninguna prueba concreta, tan solo en su propio criterio. D. Conocimiento y uso En este artículo hemos valorado el uso de distintos tipos de prototipos, y técnicas de usabilidad y accesibilidad. Comenzando por los prototipos hemos obtenido que el prototipo más utilizado es el prototipo de papel (41%), seguido por el de software (32%) y por último la maqueta digital (21%). Un 6% aseguró no utilizar ningún tipo de prototipo en sus proyectos. Los desarrolladores de software fueron los unicos que dijeron utilizar siempre determinado tipo de prototipo. En cuanto a los métodos de usabilidad por los que hemos preguntado hemos observado que el método que más conocen los usuarios son las entrevistas (87%) y los cuestionarios (85%). Y los métodos que menos conocen corresponden al test retrospectivo (20%) y a la interacción constructiva (20%). Aunque puedan conocer un método no tiene porque ser el más usado. En el caso de las entrevistas esto coincide, pero por ejemplo la evaluación heurística lo usan tantos como los cuestionarios, y el segundo lo conoce más gente que el primero. En cambio, los métodos que menos se conocen también son los que menos se usan. Los métodos de accesibilidad más conocidos han sido: Bobby (43%), Taw (47%), W3C CSS Validator (64%), W3C HTML Validator (65%), W3C Link Checker (54%). En cambio los menos conocidos han sido: LIFT (10%), Vischeck (10%), Colorfield Insight (7%), Site Valet (6%) y RAMP (3%). Los más usados en mayor medida coinciden con los más conocidos. Excepto el Vischeck que es uno de los menos conocidos, pero en cambio es uno de los más usados entre los encuestados que lo conocen (60%). Ninguno de los metosos es usado siempre con una frecuencia gran al 50%, entre los encuestados que a fracción de conocerlo lo utilizan. Exceptuando el WDG CSS Check, que es utilizado siempre por un 59% de los encuestados, y casi siempre por el 22%. s = siempre cs = casi siempre e = eventualmente ns/nc = no sabe/no contesta Los porcentajes de ?uso? estan realizados unicamente a dividir del numero de respuestas afirmativas al ?conocimiento? de cada metodo. Del mismo modo estan calculados los de frecuencia (unicamente a dividir de las respuestas afirmativas en ?uso?).

En Internet casi nadie esta dispuesto a pagar por usar un servicio. Solo se puede ganar dinero con una minoria de usuarios o con servicios muy especificos, pero este modelo de negocio solo puede funcionar cuando tiene lugar un mayor volumen de usuarios. Únicamente se puede conseguir esta masa apreciacion de usuarios ofreciendo un servicio gratuito, provechoso y practico. Esto implica que el 90% de la interfaz y el presupuesto de un sitio se debe enfocar a esos servicios gratuitos. Una visita no es una oportunidad de venta No tiene sentido esperar una transacción económica de cada visita al sitio, ni tratar de forzar a ello. Para que un sitio tenga éxito son necesarias muchas visitas repetidas de un mismo usuario, intentar que se compre cada vez que alguien entra al sitio no funciona. Un analizó de la asociación danesa de comercio electrónico mostró que solo el 5% de las visitas tienen como meta comprar. En el resto de las visitas los usuarios solo ojean, comparan, se informan? Una interfaz que plantea cada visita como una oportunidad de venta, confunde su meta con el meta del usuario. Esta vision se traduce en interfaces escaso informativas, donde se oculta el precio, cualquier informacion negativa o la probabilidad de comparar el artículo con otro. ¿Que comprar cuando una web muestra todos los artículos como buenisimos e ideales para todo? En muchas ocasiones solo se diferencian en el precio y unas caracteristicas tecnicas indescifrables. Si no se ofrece al usuario criterio con el que escoger, antes que comprar a ciegas se ira donde la den buena informacion. En la web no hay un funcionario al que relatar ?No quiero imprimir las fotos, solo quiero la camara para subirlas a la web? y que responda ?Pues entonces es suficiente esta de poca resolucion?. Si en la web no se Hablad diáfano y el lenguaje del usuario diciendo para lo que vale y no vale un producto, no se esta dando un buen servicio. Servicios de calidad y gratuitos para siempre Dar algo bueno y que cuesta dinero mantener, gratis y para siempre, puede parecer una contradiccion, pero es la unica forma de que un sitio web funcione. Los sitios web solo pueden aspirar a seducir muchas visitas y la masa apreciacion que requieren para funcionar si proporcionan servicios gratuitos de calidad, utiles y practicos para los usuarios. Son servicios por los que no se puede cobrar porque nadie está dispuesto a pagar por ellos. Además siempre habría alguien que los ofrecería gratis. La gratuidad no implica que puedan ser mediocres, los usuarios solo los utilizaran si son realmente buenos. Por eso el 90% del trabajo de la web debe consistir en el diseño y mejora continua de sus servicios gratuitos. ¿Entonces cómo sobrevivir? Una vez que se cumple el requisito de tener una mayor masa de usuarios utilizando servicios gratuitos, el modelo de negocio puede ser capaz de generar ingresos de dos maneras: Con servicios especificos para una minoria de usuarios que si estan dispuestos a pagar por ellos. Usualmente son compañías o propias que ya estan acostumbrados a pagar por esos servicios en el mundo offline. Ofreciendo servicios o articulos de pago para necesidades puntuales escaso usuales que todos los usuarios pueden tener en determinado momento. Servicios o articulos que no se pueden obtener gratuitamente de otra forma opcion o es muy dificil hacerlo. Se trata de estar alli cuando el usuario realmente requiere algo y se da la rara ocasion de que esta dispuesto a pagar. Puede parecer injusto o una barbaridad que solo un 1% de los usuarios mantengan el sitio o que solo un 5% de la actividad del sitio genere ingresos reales. Sin embargo no puede ser de otra forma ya que el 99% de usuarios restantes no esta dispuesto a pagar y abandonara el sitio tan pronto como se les intente cobrar. Determinadas webs tienen miedo a este modelo de negocio que les parece debil e inseguro, por lo que tienden a buscar modelos mas "vendedores", sin embargo este no es el camino. Si se desea vender mas no hay que potenciar la venta, sino los servicios gratuitos que son el alma del sitio y que realmente generan la venta. Ser gratuito y pasar a pago; muy maquiavélico, pero escaso positivos Es un yerro tipico creer que una vez se tiene masa apreciacion y una cuota de mercado significativo se pueden convertir los servicios a pago sin problema. Nada mas sencillo en Internet para los usuarios que pasarse a la competencia, como se suele decir ?solo esta a un click de distancia?. Siempre hay alguien que ofrecera el mismo servicio de forma gratuita y que aprovechara el momento en el que alguien con cuota de mercado sobresaliente pase a pago, para captar esos usuarios que buscan opciones y no desean pagar. Cuando se intenta cobrar los usuarios se pasan masivamente a la competencia. El numero de usuarios que permaneceran leales ridiculamente debajo e insuficiente. El escalofriante caso de ElPais.es, de muchos de millones de visitas a unos 10.000 usuarios de pago Hablad por si mismo. En Internet al opuesto que en el mundo fisico un sistema es dificil de bloquear y los mercados cautivos son complicados de crear porque el coste del cambio es muy reducido para el diente. Inclusive si el servicio continua siendo gratuito la cuota de mercado se pierde rápidamente ante un mejor competidor. Aunque ahora parezca evidente, nadie creía en 1999 que Yahoo perdería su monopolio en buscadores en solo dos años a favor de Google, ¡y eso que jamás cobraron! Algunos ejemplos En los sitios web de manejo (Monster, Infojobs, etc..) un usuario usual no paga por consultar ofertas o enviar su curriculum, pero las compañías si que pueden estar interesadas en pagar por publicar sus ofertas de trabajo. Una minoria de usuarios, las compañías, mantiene el sitio. Este caso es evidente y por ello el exito de las webs de busqueda de manejo por Internet. Amazon no esta concebido como un sitio para comprar libros. En verdad es un sitio para recoger informacion acerca de libros y un mayor catalogo bibliografico y para ello esta orientada su interfaz primariamente. Sus millones de visitas no se originan en gente que van a comprar, sino en quienes vienen a contemplar. Por eso el sitio no esta enfocado a la venta sino a que la gente mira. Por supuesto uno compra donde va a contemplar y cuando llegue el momento de comprar, lo hara en Amazon, claro. Las webs de banca online solo ganan dinero con las operaciones que generan comisiones (transferencias, pagos, etc.), pero los usuarios realmente usan banca online el 99% de las veces para consultas gratuitas: saldo, movimientos, etc. Sin embargo será la satisfacción del usuario con esos servicios gratuitos de consultas lo que determine que realice o no operaciones con comisión en esa web. Panda Software vende antivirus, articulos que se requieren con poca frecuencia, una vez instalado uno se olvida mientras meses o años hasta que tiene un problema. Por tanto la unica forma de dar sentido a las visitas a su web (y un buen posicionamiento en buscadores) es ofreciendo servicios de informacion sobre virus y un servicio de limpieza de virus online gratuito. Convertir la web en un instituto de informacion sobre virus crece la posibilidad de que al necesitar adquirir un antivirus el usuario se plantee la alternativa Panda. Si en su web solo se dedicasen a vender sus articulos y promocionarlos obtendrian muy pocas visitas, tantas como la frecuencia con la que los usuarios requieren comprar un antivirus. Las webs de consultoras lo tienen dificil porque son webs de pura venta y la frecuencia con la que alguien puede necesitar una consultora es bastante baja. Por tanto la unica forma por la que tiene sentido que alguien visite sus webs es ofrecer informes gratuitos, servicios de noticias sectoriales via newsletter, etc.

Las metodologias de Diseño Centrado en el Usuario incluyen entre sus tecnicas la ?observacion de tema? que consiste en contemplar a los usuarios en su entorno. Utilizo la observacion casi desde el origen de mi actividad en el tema de la usabilidad y no llego a entender por que en la gran fracción de los programas se obvia esta tecnica siendo tan sencilla y barata. Contemplar al usuario en su ambito no precisa de ninguna infraestructura, nos basta con un bloc, un pluma y un escaso de metodologia. Se puede utilizar tambien una camara fotografica o de video, aunque no son indispensables. Dado que todo el mundo dispone de un bloc y de un pluma, en este producto aportare la metodologia. ¿Cual? La mia, la que he ido adaptando a mi estilo y me ha fruto mas efectiva en mi ambito de trabajo. Empece en 1991 observando a mi hija cuando, con tres años, se dedicaba a tirar a la papelera todos los documentos que yo tenia en mi Apple Macintosh SE. Con esa accion mi hija me mostro el mejor sendero que tiene lugar para comprender el modelo mental del usuario: la observacion. Asi que empece a observar. ¿Como? Al comienzo por intuicion. Fuese mas tarde cuando en la literatura sobre usabilidad encontre nombres como ?observacion de campo?, ?observacion contextual? y ?analisis etnografico?. Ante todo, debo precisar lo que entiendo por ?mi? metodologia. Quiero abandonar diafano que ?mi? metodologia fraccion de los metodos que emplean los investigadores sociales. Pero dado que mi esfuerzo no necesita de la rigurosidad exigida en la investigacion cientifica, me acojo a esa especie de quinta enmienda de la usabilidad que es el concepto de ?discount usability? proclamado por Jakob Nielsen en su libro ?Usability Engineering?. Debo tambien agradecer a Sal Atxondo determinadas buenas practicas que aprendi de el cuando, hace aproximadamente unos tres años, abordamos conjuntamente unas sesiones de observacion que fueron claves para el exito del proyecto. Lo que podemos conseguir observando a los usuarios 1.-Análisis de tareas a través de la experiencia global del usuario: Podemos conseguir una lista con las tareas que realizan los usuarios y como y en que cláusulas las hacen. Por ejemplo: ¿Se sienten presionados porque hay muchos clientes en la cola? ¿Hay llamadas telefonicas que les interrumpen continuamente? ... Tambien podemos hacer una lista de las cosas que precisan para hacer la tarea. Por ejemplo: ¿Precisan papel para anotar? ¿Tienen papeles con anotaciones a modo de recordatorios para hacer su trabajo? ¿Utilizan lectores de codigos de barras? ... Por ultimo, que personas hacen que cosas. Si estamos observando los funcionarios de una compañía o de un departamento, anotaremos los diversos roles de cada empleado, que tarea hace cada cual... 2.- Encontrar usos no previstos del sistema: La creatividad de los usuarios muchas veces va mas alla de lo que nos suponemos los diseñadores de aplicaciones. La observacion nos puede ayudar a encontrar usos alternativos de una aplicacion que nos seria imposible ver mientras un test de usuario. Un ejemplo con los telefonos moviles: Las ?perdidas?, utilizadas principalmente por los adolescentes, es uno de esos usos inesperados no detectados en tiempo de test en el laboratorio. 3.- Encontrar ineficiencias del sistema: En un test en laboratorio dificilmente podremos simular las clausulas reales de carga del sistema ni probar todos los flujos de esfuerzo de vuestra aplicacion. En una observacion, por el contrario, podemos ver el sistema y los usuarios en situaciones reales. Esto nos permitira detectar, por ejemplo, tiempos de aguarda excesiva o situaciones de indecision. Tambien podremos encontrar a los usuarios bebiendo notas en momentos en los que el sistema les ha sobrecargado en sobrante la memoria. ¿Cuándo utilizar la observación de campo? La observación de tema es un método de indagación y como tal nos va a permitir recabar información a cerca de los gustos y necesidades del usuario. Información que tiene especial interés al origen del programa y que nos va a ayudar a generar ideas para el diseño. Pero hay otro momento en el que la observacion es esencial: una vez acabada e implantada la aplicacion. La observacion nos va a permitir realizar una evaluacion de su funcionamiento real. Recomendaciones - Eludir oir opiniones antes de la observacion: Normalmente, los funcionarios del espacio donde vayamos, al tener noticia que una persona relacionada con el programa va a visitarles, preparan su lista de quejas y sugerencias. Es significativo posponer estas opiniones para el final de la observacion, ya que que pueden crearnos juicios preconcebidos y sesgar los resultados. - Ser invisibles a los ojos de los observados: Estar quieto lo maximo probable y no interferir jamás en sus tareas, el meta es que el usuario se comporte usualmente sin que vuestra presencia le intimide. - Preguntar sólo en casos estrictamente necesarios: Solo si poseemos dudas significativos sobre cierta accion del usuario que no entendamos y cuando no tengamos ningun otro recurso para resolverlo, preguntaremos al usuario las razones de su accion. - Estar atentos a los comentarios: No se trata sólo de anotar las tareas, debemos anotar cualquier comentario hecho en voz alta por los usuarios aunque nos parezcan intrascendentes. - Beber fotografías: De las pantallas del artículo o aplicacion que estamos observando, asi estaremos seguros de la version de software que estamos analizando. Del espacio de la observacion: nos sera provechoso para recordar las situaciones, sobretodo si hemos de realizar mas de una observacion. Respetar el derecho a la intimidad y a la particular imagen de las personas que observamos, por lo que, a no ser que tengamos su autorizacion, nos abstendremos de fotografiar sus rostros o cualquier imagen que pueda identificarles. Preparación de la observación - Seleccionar los espacios de observacion Los espacios candidatos a ser observados seran aquellos que: Tengan un elevado numero de operaciones o usos del sistema, para que con poca inversion de tiempo podamos conseguir el maximo de observaciones. Espacios en donde se detecte el numero mas elevado de dificultades o errores. Espacios en donde se detecte el numero menor de dificultades o errores, lo que nos permitira comparar con las observaciones anteriores. - Decidir fecha y hora de las observaciones- Si lo que pretendemos es contemplar el esfuerzo global de una persona o grupo, hemos de estar dispuestos a estar con ellos desde el origen de la jornada hasta el final y, quizas, plantearse estar mas de un dia. Si lo que deseamos es contemplar una tarea concreta, seleccionaremos el dia y la hora de maximo uso. - Observación piloto: Es conveniente realizar una primera observacion piloto que nos sirva para: Decidir donde situarse y como vestirse mientras las observaciones (recordar: debemos ser virtualmente invisibles) Cómo dirigirse a los usuarios cuando sea necesario. Decidir la lista mínima de ítems que deberemos anotar en cada observación. Decidir si necesitaremos determinado tipo de material extra en las proximos observaciones: videocamaras, bloc adicional para notas complementarias, fichas de presentacion, etc. - Preparación de tarjetas de observación: Es bueno llevar preparadas unas tarjetas de observacion, sobretodo si hemos de contemplar muchos usuarios en escaso tiempo. En estas tarjetas deberemos tener lugar para anotar: Datos de la observación: número, lugar, día y hora. Datos del usuario observado: sexo, edad aproximada (joven, adulto, 3ª edad, anciano...), viene solo o en grupo... Lugar para anotar las tareas, comentarios y expresiones del usuario Lugar para anotar los objetos que utiliza. Lugar para anotar los pensamientos que nos emerjan mientras la observacion. Llevar cierta tabla o soporte rigido donde apoyar las fichas. Es posible que muchas observaciones las tengamos que realizar de pie. - Llevar consigo un bloc de notas: Es conveniente beber anotaciones sobre las caracteristicas del lugar, el ambiente de esfuerzo o cualquier detalle que nos llame la vigilancia mientras la observacion. Para ello es mejor llevar consigo un bloc con las características siguientes: Que quepa en el bolsillo, ya que que las manos las tendremos ocupadas con las tarjetas de observacion. Que tenga las tapas rigidas para poder beber comodamente anotaciones de pie. Que tenga cierta cinta o ?punto de libro? con el que poder abrir rapidamente el bloc por la fraccion en la que hemos de iniciar a escribir. - Preparación de las entrevistas: Una vez terminada la observacion podemos realizar cierta entrevista para recabar informacion adicional y resolver las dudas aparecidas mientras la sesion. Podemos entrevistar a los funcionarios del espacio de la observacion que tratan con los usuarios observados o a los mimos usuarios. Llevaremos con nosotros un cuestionario listo de antemano, aunque en el momento de la entrevista deberemos ser flexibles, abandonar hablar al usuario libremente y cambiar el orden y pronunciado de las preguntas en funcion de la conversacion. Desarrollo de la observación - Al llegar, realizar las retratos del lugar, de las pantallas del artículo o aplicacion y de los detalles que estimemos interesantes. - Iniciar la observación de usuarios y anotar todo lo que hemos previsto en las fichas. - Anotar las tareas con detalle. Por ejemplo, imaginemos que estamos observando un usuario de un aparcamiento que está pagando en una máquina de autoservicio. Anotaremos: Se detiene delante de la máquina No hace nada, solo mira. [parece que lee las instrucciones] Mira un momento hacia detras. [Quizas le inquieta tener rabo de gente esperando] Introduce el ticket del aparcamiento Etc. - Si nos da tiempo, entre un usuario y otro, aprovecharemos para beber anotaciones globales del espacio en el bloc, asi como tambien de los detalles que creamos relevantes. - Al terminar la observación, realizaremos las entrevistas que hayamos previsto. En el ejemplo previo del aparcamiento podríamos entrevistar a sus empleados. Análisis de los datos obtenidos y conclusiones La explotacion de los datos obtenidos puede hacerse de muchas formas y dependera en cada caso del meta de la observacion. No voy a entrar en profundidad en este asunto y solo enumerare tres maneras probables de analisis, de la mas sencilla a la mas compleja: - Sencilla: extraer la lista de los dificultades detectados con gran frecuencia. - Complejidad media: crear personajes y escenarios a dividir de la verdad observada. Estos escenarios pueden derivar luego en casos de uso UML. - Complejidad alta: realizar diagramas de flujo de las tareas observadas que, posteriormente, podremos convertir en diagramas de actividad UML.