Este es un ejemplo de lo que se puede hacer con un sistema de realidad aumentada muy conocido(AR Toolkit), imaginacion y creatividad. No hay nada que inventar solo es cuestion de innovar.
DIPLOMA : Immersive Rail Shooter from David Arenou on Vimeo.
jueves, 4 de marzo de 2010
Agregar inmersion a los video juegos es el futuro
§La inmersion en un sistema de realidad virtual se refiera a la sensacion del usuario de "estar ahi" gracias a un sistema que permita dar esa sensacion.
Este es un ejemplo de lo que se puede hacer con un sistema de realidad aumentada muy conocido(AR Toolkit), imaginacion y creatividad. No hay nada que inventar solo es cuestion de innovar.
Este es un ejemplo de lo que se puede hacer con un sistema de realidad aumentada muy conocido(AR Toolkit), imaginacion y creatividad. No hay nada que inventar solo es cuestion de innovar.
lunes, 1 de marzo de 2010
lunes, 1 de febrero de 2010
A retener y explorar
He aqui una serie de articulos que nos invita a leer la revista Userfocus
Card Games for Information Architects
Card Games for Information Architects
jueves, 21 de enero de 2010
Interfaces plegables
Cada dia nos sorprenden mas y mas con lo delgado que puede ser una pantalla de computadora o de television. Le tecnologia avanza y he aqui una de las ideas que hoy surgen y que el dia de mañana formaran parte del dia a dia.
martes, 5 de enero de 2010
La fábula del diseñador centrado en el usuario
David Travis escribió una fábula sobre el diseñador centrado en el usuario. Es una historia fácil de leer, entretenida y muy instructiva. Sin llegar a ser un “saber hacer” te da al menos una nocion del “que hacer” en lo referente al diseño de software centrado en el usuario, algo de lo que siempre hablamos en este blog como método a seguir para el desarrollo de interfaces.
A groso modo y sin intención de transcribir el libro los puntos más destacados del desarrollo centrado en el usuario según David Travis son.
“El diseño visual (organización de los componentes visuales para evitar obstrucciones que impidan acceder a las opciones importantes) es solo una parte de la experiencia del usuario con la tecnología“.
“La tecnología es solo una parte de la solución no lo es todo“.
“Hay que centrarse siempre en las personas que van a usar nuestros productos no en el diseño visual o el uso de lo último en tecnología“.
Para ello hay que basar todo desarrollo en tres pilares:
1.- Temprano y continua comprensión de los usuarios y las tareas que realizan. Para ellos muchas herramientas existen pero el autor centra su solución al uso de Personas nosotros en UsiXML usamos un modelo del usuario. Sin importar como se modela el usuario la fuente de información que crea estos usuarios es de vital importancia y esta puede ser a través de:
* investigación de campo con los reales usuarios del sistema para ver lo que hacen y determinar sus características.
* Visitas regulares al cliente para determinar: motivaciones y perfiles de usuario, ambiente de trabajo y rutas prioritarias (tareas criticas que un usuario tiene que hacer lo más pronto y fácil como sea posible, ojo ). A esto yo agregaría, tecnología o modelo de dispositivos con los que se cuenta. Todo esto sigue en línea con lo que se hace en UsiXML.
* Es imposible hacer que todo sea fácil y de simple acceso, hay que dar prioridades a las cosas y es ahí donde la noción de rutas criticas ayuda a encontrar el balance necesario. En el modelo de workflow nosotros introducimos un concepto similar llamado cuellos de botella que permite identificar las etapas donde se requiere mayor atención debido a la falta de usuarios a realizar la tarea que podría estar relacionada con la complejidad de la tarea o la necesidad de más personal.
* Las visitas a los clientes ayudan a determinar las rutas criticas en función de las metas que buscan sus usuarios.
* Modelar los procesos y las tareas es primordial y para ello nada mejor que el modelado de workflow.
2.- Medición empírica del comportamiento del usuario. Hay que estar seguros de que el diseño funciona como la gente lo espera. Considerar la primera impresión de tus usuarios, sus pensamientos, sus quejas, para ello:
* Test de usabilidad. Considerando las ventajas y desventajas que se puede uno topar. La gente no siempre va a querer transmitir lo que esperan ya que ignoran cuales podrían ser los alcances del sistema.
* Pon a pruebas las rutas criticas de tu sistema.
* Que los usuarios mientras trabajan hablen en voz alta para identificar que aspectos de la interfaz son confusos.
* Medir la usabilidad: cuantos usuarios logran completar la tarea con éxito, eficiencia en lograr la tarea normalmente medida en tiempo, satisfacción con el usuario.
3.- Diseño iterativo. Porqué es necesario hacer prueba y error constantes y por ello no podemos estar codificando el sistema real constantemente es que se requiere de basar las iteraciones en prototipos. Diseños que pueden ser mejorados usando software como el que provee UsiXML para hacer prototipos de interfaces.
* Las iteraciones harán que las mejores cosas de los prototipos sean seleccionados como elementos del sistema.
Muchas empresas tienden a decir que la captura y análisis de requerimientos es centrada en el usuario pero no siguen ninguno de los principios del diseño centrado en el usuario. Esto es básicamente por que creen que ellos entienden lo que necesita el cliente. La investigación sobre las necesidades del usuario no es constante ni comienza al principio del proyecto. La investigación de campo se focaliza en lo que la gente piensa y no en lo que hace. Las decisiones sobre qué hacer con un sistema siempre se basan en decisiones del personaje más importante del grupo de desarrollo y no con los usuarios finales.
Vale la pene leer la historia hay mucho que aprender.
A groso modo y sin intención de transcribir el libro los puntos más destacados del desarrollo centrado en el usuario según David Travis son.
“El diseño visual (organización de los componentes visuales para evitar obstrucciones que impidan acceder a las opciones importantes) es solo una parte de la experiencia del usuario con la tecnología“.
“La tecnología es solo una parte de la solución no lo es todo“.
“Hay que centrarse siempre en las personas que van a usar nuestros productos no en el diseño visual o el uso de lo último en tecnología“.
Para ello hay que basar todo desarrollo en tres pilares:
1.- Temprano y continua comprensión de los usuarios y las tareas que realizan. Para ellos muchas herramientas existen pero el autor centra su solución al uso de Personas nosotros en UsiXML usamos un modelo del usuario. Sin importar como se modela el usuario la fuente de información que crea estos usuarios es de vital importancia y esta puede ser a través de:
* investigación de campo con los reales usuarios del sistema para ver lo que hacen y determinar sus características.
* Visitas regulares al cliente para determinar: motivaciones y perfiles de usuario, ambiente de trabajo y rutas prioritarias (tareas criticas que un usuario tiene que hacer lo más pronto y fácil como sea posible, ojo ). A esto yo agregaría, tecnología o modelo de dispositivos con los que se cuenta. Todo esto sigue en línea con lo que se hace en UsiXML.
* Es imposible hacer que todo sea fácil y de simple acceso, hay que dar prioridades a las cosas y es ahí donde la noción de rutas criticas ayuda a encontrar el balance necesario. En el modelo de workflow nosotros introducimos un concepto similar llamado cuellos de botella que permite identificar las etapas donde se requiere mayor atención debido a la falta de usuarios a realizar la tarea que podría estar relacionada con la complejidad de la tarea o la necesidad de más personal.
* Las visitas a los clientes ayudan a determinar las rutas criticas en función de las metas que buscan sus usuarios.
* Modelar los procesos y las tareas es primordial y para ello nada mejor que el modelado de workflow.
2.- Medición empírica del comportamiento del usuario. Hay que estar seguros de que el diseño funciona como la gente lo espera. Considerar la primera impresión de tus usuarios, sus pensamientos, sus quejas, para ello:
* Test de usabilidad. Considerando las ventajas y desventajas que se puede uno topar. La gente no siempre va a querer transmitir lo que esperan ya que ignoran cuales podrían ser los alcances del sistema.
* Pon a pruebas las rutas criticas de tu sistema.
* Que los usuarios mientras trabajan hablen en voz alta para identificar que aspectos de la interfaz son confusos.
* Medir la usabilidad: cuantos usuarios logran completar la tarea con éxito, eficiencia en lograr la tarea normalmente medida en tiempo, satisfacción con el usuario.
3.- Diseño iterativo. Porqué es necesario hacer prueba y error constantes y por ello no podemos estar codificando el sistema real constantemente es que se requiere de basar las iteraciones en prototipos. Diseños que pueden ser mejorados usando software como el que provee UsiXML para hacer prototipos de interfaces.
* Las iteraciones harán que las mejores cosas de los prototipos sean seleccionados como elementos del sistema.
Muchas empresas tienden a decir que la captura y análisis de requerimientos es centrada en el usuario pero no siguen ninguno de los principios del diseño centrado en el usuario. Esto es básicamente por que creen que ellos entienden lo que necesita el cliente. La investigación sobre las necesidades del usuario no es constante ni comienza al principio del proyecto. La investigación de campo se focaliza en lo que la gente piensa y no en lo que hace. Las decisiones sobre qué hacer con un sistema siempre se basan en decisiones del personaje más importante del grupo de desarrollo y no con los usuarios finales.
Vale la pene leer la historia hay mucho que aprender.
miércoles, 16 de diciembre de 2009
Para entender el contexto y el uso de sistemas de workflow.
Toda empresa, privada o de gobierno, de cualquier giro y cualquier tamaño tiene y está regida y organizada por un flujo de procesos (workflow) del cual en la mayoría de los casos no están conscientes. El workflow de las empresas es muy importante ya que determina la forma en que se distribuye el trabajo, quien lo tiene que hacer, donde lo tiene que hacer y como la va a hacer.
Que podemos hacer nosotros:
1. Definir el workflow de una empresa. Mediante recopilación de información mediante entrevistas y la observación directa de los empleados es importante para lograr entender el qué está haciendo. Esto se modela mediante tablas y una notación grafica que describen la forma en que está organizada la empresa. Esta notación favorece la discusión y el dialogo con el cliente para que valide tu modelo.
2. Una vez modelada la empres tal cual es se procede a analizar la forma en que se puede mejorar. El problema clásico que nos encontramos es que todo mundo hace las cosas de forma secuencial cuando muchas actividades pudieran ser realizadas en paralelo. Esto es muy importante sobre todo en empresas con flujo de documentos que generalmente por una mala distribución generan tiempos de espera innecesarios.
3. Otra ventaja de un modelo de workflow es que se pude determinar la asignación del trabajo. Con muchas ventajas asociadas. Una tarea, por ejemplo procesar una solicitud de vacaciones, podría ser delegada a otro elemento de la empresa que ha sido reconocido como capaz de tomar las riendas de dicho trabajo en caso de que el recurso originalmente asignado a la tarea este indisponible. Note que a veces los sistemas de cómputo quedan atorados ya que los permisos de acceso a expedientes están limitados a ciertos usuarios. Para ellos existen 48 patrones de asignación de tareas los cuales pueden ser definidos en tiempo de diseño del sistema o asignarse en tiempo de ejecución.
4. Manejo de agendas. La organización requiere del manejo de sistemas al interior que permitan y favorezcan la comunicación entre los diferentes actores. Cada que una empleado sea asignado con una tarea requiere de un mecanismo que le anuncie y a su supervisor otro que le permita identificar que dicha tarea ha sido asignada, denegada, delegada.
5. Identificación de cuellos de botella de la empresa. Durante la fase de diseño y mediante la recolección de datos se puede determinar donde hay necesidad o de aumentar el número de recursos o de hacer las tareas más eficientes para evitar que se detenga el progreso del trabajo. Durante el funcionamiento del sistema se pueden monitorear las procesos y ver donde están las cosas bien, regular y mal.
Todo esto es la parte del diseño obviamente un grupo de desarrolladores se encargaría de implementar un sistema que soporte estas características.
Por otro lado sobre los sistemas nosotros podemos.
1. Diseñar prototipos de las interfaces que ayuden al usuario final a coincidir con lo que esperan
2. Evaluar la usabilidad del producto final antes de ser entregado. Todo sistema por definición se espera sea útil, es decir, cumpla con el propósito para el cual fue diseñado. Sin embargo, eso no quiere decir que será usado de forma eficiente. Para ello hay que evaluar si el sistema diseñado, o incluso el que usan cumple con el mínimo de normas de usabilidad. En caso contrario, se debe mejorar el sistema, o en caso de que sea un sistema existente, entonces tienes elementos para demostrar que requieren algo nuevo.
3. Basados en el workflow de la empresa se contribuye a determinar de forma eficiente la compra de software. Para esto en ejemplo, una empresa X compra el sistema de software de contabilidad SAP. Los contadores lo conocían y era la forma como sabían llevar sus estados contables. La gerencia debía entregar reportes en formatos de hojas de cálculo de Excell. La línea de producción generaba estadísticas en hojas de papel. Problema a fin de mes la gerencia dedicaba al menos una semana a la generación del balance financiero. Si se hubiera estudiado el workflow se hubieran dado cuenta que usar SAP era un gasto múltiple para la empresa, un software que solo facilitaba la vida de los contadores pero ponía a trabajar a todos el doble, incluidos los contadores que después tenían que capturar dos veces la misma información en hojas de cálculo en Excell. Un poco de visión mostraba que era mejor capacitar a los contadores en el uso de Excell y los formatos necesarios para llevar la contabilidad.
Mas datos se pueden encontrar en el sitio de FlowiXML
Incluso se puden contratar los servicios especializados a traves de la UCL. En breve ya disponible esta consultoria en Puebla, Mexico.
Que podemos hacer nosotros:
1. Definir el workflow de una empresa. Mediante recopilación de información mediante entrevistas y la observación directa de los empleados es importante para lograr entender el qué está haciendo. Esto se modela mediante tablas y una notación grafica que describen la forma en que está organizada la empresa. Esta notación favorece la discusión y el dialogo con el cliente para que valide tu modelo.
2. Una vez modelada la empres tal cual es se procede a analizar la forma en que se puede mejorar. El problema clásico que nos encontramos es que todo mundo hace las cosas de forma secuencial cuando muchas actividades pudieran ser realizadas en paralelo. Esto es muy importante sobre todo en empresas con flujo de documentos que generalmente por una mala distribución generan tiempos de espera innecesarios.
3. Otra ventaja de un modelo de workflow es que se pude determinar la asignación del trabajo. Con muchas ventajas asociadas. Una tarea, por ejemplo procesar una solicitud de vacaciones, podría ser delegada a otro elemento de la empresa que ha sido reconocido como capaz de tomar las riendas de dicho trabajo en caso de que el recurso originalmente asignado a la tarea este indisponible. Note que a veces los sistemas de cómputo quedan atorados ya que los permisos de acceso a expedientes están limitados a ciertos usuarios. Para ellos existen 48 patrones de asignación de tareas los cuales pueden ser definidos en tiempo de diseño del sistema o asignarse en tiempo de ejecución.
4. Manejo de agendas. La organización requiere del manejo de sistemas al interior que permitan y favorezcan la comunicación entre los diferentes actores. Cada que una empleado sea asignado con una tarea requiere de un mecanismo que le anuncie y a su supervisor otro que le permita identificar que dicha tarea ha sido asignada, denegada, delegada.
5. Identificación de cuellos de botella de la empresa. Durante la fase de diseño y mediante la recolección de datos se puede determinar donde hay necesidad o de aumentar el número de recursos o de hacer las tareas más eficientes para evitar que se detenga el progreso del trabajo. Durante el funcionamiento del sistema se pueden monitorear las procesos y ver donde están las cosas bien, regular y mal.
Todo esto es la parte del diseño obviamente un grupo de desarrolladores se encargaría de implementar un sistema que soporte estas características.
Por otro lado sobre los sistemas nosotros podemos.
1. Diseñar prototipos de las interfaces que ayuden al usuario final a coincidir con lo que esperan
2. Evaluar la usabilidad del producto final antes de ser entregado. Todo sistema por definición se espera sea útil, es decir, cumpla con el propósito para el cual fue diseñado. Sin embargo, eso no quiere decir que será usado de forma eficiente. Para ello hay que evaluar si el sistema diseñado, o incluso el que usan cumple con el mínimo de normas de usabilidad. En caso contrario, se debe mejorar el sistema, o en caso de que sea un sistema existente, entonces tienes elementos para demostrar que requieren algo nuevo.
3. Basados en el workflow de la empresa se contribuye a determinar de forma eficiente la compra de software. Para esto en ejemplo, una empresa X compra el sistema de software de contabilidad SAP. Los contadores lo conocían y era la forma como sabían llevar sus estados contables. La gerencia debía entregar reportes en formatos de hojas de cálculo de Excell. La línea de producción generaba estadísticas en hojas de papel. Problema a fin de mes la gerencia dedicaba al menos una semana a la generación del balance financiero. Si se hubiera estudiado el workflow se hubieran dado cuenta que usar SAP era un gasto múltiple para la empresa, un software que solo facilitaba la vida de los contadores pero ponía a trabajar a todos el doble, incluidos los contadores que después tenían que capturar dos veces la misma información en hojas de cálculo en Excell. Un poco de visión mostraba que era mejor capacitar a los contadores en el uso de Excell y los formatos necesarios para llevar la contabilidad.
Mas datos se pueden encontrar en el sitio de FlowiXML
Incluso se puden contratar los servicios especializados a traves de la UCL. En breve ya disponible esta consultoria en Puebla, Mexico.
jueves, 10 de diciembre de 2009
Beneficios del paradigma basado en modelos
Un metodo para desarrollo de software promovido por el object management group (www.omg.org) es conocido como ingenieria manajeda por modelos (MDA por sus siglas en ingles) promueve que el uso de modelos para describir los diferentes componentes de una aplicación pueden reducir de manera significativa los retos actuales del desarrollo de sistemas interactivos. Retos que tienen que ver con la diversidad de dispositivos de computo(celular, tablet pc), lenguajes de programación (declarativo, imperativo), modalidades de interacción (vocal, grafica, física, táctil) y el contexto de uso. Este ultimo muy complejo y que en una visión simplificada pero suficientemente compleja debería considerar variaciones en los tipos de usuario (experto, novato, categoría de edad, habil), ambiente donde ejecuta su aplicación (trabajo, casa) y la plataforma donde trabaja que involucra la combinación de dispositivos de entrada y salida de hardware y software requeridos para la interacción.
Si logramos poner todas estas variables en modelos suficientemente abstractos y logramos definir la forma de transformar el modelo en solución dependiendo del objetivo que se tenga entonces podemos el espacio de soluciones que un equipo de desarrollo requeriría para resolver el problema de la multiplicidad de posibles soluciones que requiere.
Para centrarte en esta área yo te recomiendo leer estos artículos de Jean Vanderdonckt, que yo encuentro geniales:
A MDA-Compliant Environment for Developing User Interfaces of Information Systems
Model-Driven Engineering of User Interfaces: Promises, Successes, Failures, and Challenges
Multimodality for Plastic User Interfaces: Models, Methods, and Principles, in “Multimodal user interfaces: from signals to interaction
Y sobre tutoriales y cursos bájate los slides de slideshare que él mismo ha subido
http://www.slideshare.net/jeanvdd/modeldriven-engineering-of-user-interfaces
http://www.slideshare.net/search/slideshow?q=jean+vanderdonckt&submit=post
Si logramos poner todas estas variables en modelos suficientemente abstractos y logramos definir la forma de transformar el modelo en solución dependiendo del objetivo que se tenga entonces podemos el espacio de soluciones que un equipo de desarrollo requeriría para resolver el problema de la multiplicidad de posibles soluciones que requiere.
Para centrarte en esta área yo te recomiendo leer estos artículos de Jean Vanderdonckt, que yo encuentro geniales:
A MDA-Compliant Environment for Developing User Interfaces of Information Systems
Model-Driven Engineering of User Interfaces: Promises, Successes, Failures, and Challenges
Multimodality for Plastic User Interfaces: Models, Methods, and Principles, in “Multimodal user interfaces: from signals to interaction
Y sobre tutoriales y cursos bájate los slides de slideshare que él mismo ha subido
http://www.slideshare.net/jeanvdd/modeldriven-engineering-of-user-interfaces
http://www.slideshare.net/search/slideshow?q=jean+vanderdonckt&submit=post
Suscribirse a:
Entradas (Atom)
Entradas
