jueves, 29 de marzo de 2012

Tarea 3 - Modelado y Simulación

Para esta tarea, se nos dio a escoger libremente una librería aleatoria para realizarle diferentes pruebas con el objetivo de determinar si este generador es en realidad, o se puede considerar aleatorio, si sigue alguna distribución, y si tiene características de generadores aleatorios.

Herramientas


Librería de generación de números aleatorios - random (python)


Como librería para generar números escogí random de python. Es de simple uso y le podemos dar rangos específicos en los cuales queremos números aleatorios. 


Librería de pruebas estadísticas - scipy

Para realizar algunas pruebas estadísticas que no tenemos incluidas en la librería math de python, utilizaré scipy que contiene funciones interesantes que podremos usar, como chi2, con la cual podremos calcular el chi square necesario para realizar algunas pruebas a las secuencias aleatorias.

a) Los números se acoplan a una distribución?

Para determinar esto, necesitaremos una muestra suficientemente grande. Esto debido a que la forma de saber si nuestro generador de números aleatorios se acopla a una distribución, necesitamos graficar la proporción de la aparición de cada número aleatorio.

Para esto podemos dividir un rango de números, digamos del 0 al 100, en canastas de igual magnitud, y contar cuantas veces cae un número aleatorio en cada canasta, entonces graficariamos esto para ver el comportamiento, y conocer a que distribución se acopla.

Lo que hice yo, fue utilzar un método acumulativo como el que se usó en el examen, para poder generar números aleatorios con la distribución poisson, a partir de uniformes usando random.randint() de python. Entonces genere 100,000 de estos números usando lambda = 10, y conte el número de apariciones de cada número aleatorio usando canastas de 2 en 2. Al final solo lo grafiqué, el resultado se puede ver a continuación:

(No pude hacerla mucho más visualmente atractiva debido primordialmente a que agregando más números aleatorios causaba que el programa tardara una eternidad en correr. Aún así, se puede ver que la secuencia sigue en efecto la distribución poisson)

Él código es el siguiente:



b) Test para saber si presentan características de números aleatorios


Es imposible probar a ciencia cierta si una secuencia de números dada(y el generador que la produjo) es  perfectamente aleatoria. RANDOM.ORG explica esto usando una comic de DILBERT bastante gracioso, pero cierto, que se puede ver a continuación:

El hecho de que la creatura genere el número aleatorio 6 veces seguidas, nos podría hacer creer que en verdad no es una secuencia aleatoria. Pero el hecho es que puede ser que ya haya estado generando otros números previamente, y justamente en el momento en que pasaron a checarla, genero 6 nueves seguidos, es muy poco probable, pero no podemos saber si en verdad se equivoco o no.

Entonces si no podemos provar la aleatoreidad, lo que hacemos es tomar diversas secuencias de un generador aleatorio, y someterlas a pruebas estadísticas. Cada que la secuencia pase más pruebas, podemos tener más confianza en la aleatoreidad de los números, y con esto la confianza en el generador.

Pero ya que debemos esperar que algunas secuencias aparezcan no aleatorias, es decir que aparezca el mismo número varias veces seguidas, podemos esperar que las secuencias fallen algunas pruebas. Pero si muchas secuencias fallan las pruebas, debemos de sospechar del generador. 

Lo mismo sería al contrario, si nuestro generador pasa todas las pruebas, deberíamos sospechar, ya que al pasar las pruebas significa que el generador no esta haciendo números aleatorios como los antes mencionados(que sean cadenas repetidas, pero aún así aleatorios), y aunque estos a primera vista no se vean aleatorios, lo son.

Test de Frecuencia (Monobit)

Defecto que detecta: Demasiados zeros o unos
Propiedad que busca: Probabilidad global igual 

Parámetros: 
  • n - largo de la secuencia
Descripción:

Ésta prueba se concentra en la proporción de zeros y unos de una secuencia entera. El propósito es encontrar si el número de unos y zeros en una secuencia es aproximadamente el mismo, como se esperaría de una verdadera secuencia aleatoria.

Procedimiento:


1. Convertimos los ceros del programa a -1, y los sumamos todos en una sola variable, a la que llamaremos Sn.

2. Calculamos la siguiente prueba estadística:
3. Calculamos P - value de la siguiente forma:
Donde erfc es la función error complementaria.

4. Si P - value < 0.01, se concluye que la secuencia no es aleatoria. De otra forma la secuencia es aleatoria.

Código:


#Test de Frecuencia(Monobit)
#Funcion que hace la prueba de frecuencia(monobit) a una lista
#que continene una secuencia aleatoria de ceros y unos
def frequency_test(lista):
  i = 0
  suma = 0
  n = len(lista)
  for i in range(len(lista)):
 if lista[i] == 0:
   lista[i] = -1
        suma = suma + lista[i]
  suma_abs = abs(suma)/math.sqrt(n)
  p_value = math.erfc(suma_abs/math.sqrt(2))
  if p_value < 0.01:
   print "Frequency Test: Not passed\n"
  else:
 print "Frequency Test: Passed\n"

Test de Frecuencia (Bloques)

Defecto que detecta: Demasiados zeros o unos
Propiedad que busca: Probabilidad local igual

Parámetros: 
  • n - largo de la secuencia
  • m - el largo de cada bloque
  • ε - secuencia de bits generada
Descripción:

El enfoque de esta prueba es la proporción de unos dentro de bloques de m bits. El proósito es determinar si una frecuencia de unos dentro de un bloque es aproximadamente m/2, como se esperaría de la aleatoreidad. Haciendo bloques de tamaño 1, estaríamos haciendo la prueba de frecuencia (monobit). 

Procedimiento:

1. Partición de la secuencia en bloques de tamaño  N, descartando bits no usados.
2. Determinar la proporción de unos con la fórmula: 
3. Calcular la prueba estadística:

4. Calcular P - value usando la fórmula: 
Donde chidist es la distribución chi al cuadrado y df es el grado de libertad (número de bloques - 1)

5. Si el valor de P - value < 0.01, se concluye que la secuencia no es aleatoria. De otra forma la secuencia es aleatoria.

Código:

#Test de Frecuencia (Bloques)
#Esta funcion toma de parametro una lista con
#la secuencia aleatoria de unos y ceros que se
#desea poner a prueba
def frequency_test_block(list):
  m = 10
  n = len(list)
  N = int(n/m)
  blocks = []
  i = 0
  while(len(blocks) != N):
    blocks.append(list[i:(i+m)])
    i = i + m
  sumas = []
  for i in range(len(blocks)):
    sumas.append(0)
    for j in range(len(blocks[i])):
 sumas[i] = sumas[i] + blocks[i][j]/float(m)
  #print sumas
  x_2 = 0
  for i in range(N):
    x_2 = x_2 + math.pow((sumas[i] - .5), 2)
  x_2 = x_2 * 4*m
  df = m - 1
  p_value = chi2.cdf(x_2, df)
  if p_value < 0.01:
 print "Frequency Test with Blocks: Not Passed"
  else:
 print "Frequency Test with Blocks: Passed"

Runs Test

Defecto que detecta: Si el cambio entre unos y ceros en la secuencia es muy rápido o muy lento.
Propiedad que busca: Depedenca secuencial (local)

Parámetros: 
  • n - largo de la secuencia
  • ε - secuencia de bits generada
Descripción:

El centro de atención de esta prueba es el número total de "corridas"  en una secuencia, donde cada corrida es una secuencia ininterrumpida de bits idénticos.  Una corrida de largo k consiste en en k bits idénticos y empieza y termina antes y después con un bit del valor opuesto. El propósito de esta prueba es determinar si el número de corridas de unos y ceros de varios largos, es el esperado para una secuencia aleatoria. En particular la prueba determina si la oscilación entre ceros y unos es muy rápida o muy lenta.

Procedimiento:

1. Calcular la proporción de unos de la secuencia de bits generada con la fórmula: 
2. Determinar si el pre-test de frecuencia es pasado. Si π −1 2 ≥ τ , el test no será necesario
3. Calcular la prueba estadística: 
Donde r(k) = 0 si εk = εk+1, y r(k) = 1 de otra forma.

4. Calcular P - value con la fórmula:

5. Si el valor de P - value < 0.01, la secuencia no es aleatoria. De otra forma la secuencia es aleatoria.

Código:

def runs_test(lista):
  suma = 0
  n = len(lista)
  for i in range(len(lista)):
    suma = suma + lista[i]/float(n)
  if abs(suma - .5) >= (2/math.sqrt(n)):
    print "Runs test does not need to be performed"
    return 
  else:
    v_obs = 1
    r_k = 0
    for i in range(n-1):
 if lista[i] == lista[i + 1]:
   r_k = 0
 else:
   r_k  = 1
  v_obs = v_obs + r_k
    p_value = math.erfc((abs(v_obs - (2*n*suma*(1-suma))))/(2*math.sqrt(2*n)*suma*(1-suma))) 
    if p_value >= 0.01:
 print "Runs Test: Passed"
    else:
 print "Runs Test: Not passed"

Test for the largest run of ones in a block

Defecto que detecta: Si el cambio entre ceros y unos en la secuencia es muy rápida o muy lenta.
Propiead que busca: Dependencia secuencial (local)

Parámetros:
  • n - largo de la secuencia.
  • ε - secuencia de bits generada
  • m - Largo de cada bloque. La prueba necesita que se acomode a partir de la siguiente tabla:
  • N - número de bloques, definido de acuerdo a M.
Descripción:

El test se enfoca en la corrida más larga de unos dentro de bloques de m-bits. El propósito de éste test es determinar si el largo de la corrida más larga de unos dentro de la secuencia es consistente con el que se esperaría en una secuencia aleatoria. Una irregularidad esperada en el largo de la corrida más larga de unos implica que también hay una irregularidad en el largo esperado de la corrida más larga de ceros. Entonces solo es necesaria una prueba para los unos.

Ejecución de las Pruebas



Referencias:

Wiki Contributions - Week 8

For this week, I was appointed with a new and interesting task. To do a web interface using Ruby on Rails. This web interface would be used to distribute tasks between the nodes of a cluster, check the state of the nodes, and some other stuff. So to do this, I first installed Ruby on Rails and started testing and reading about it.

So to contribute in the wiki, this week I'll add a tutorial of how to install ruby on rails and all the needed stuff there. And I'll be uploading code to something like Github to keep the code online and updated. Also if I found something interesting about Ruby On Rails I'll upload it in the wiki as well.

Anyway, the link to the wiki is the following:
 - Ruby On Rails

For the laboratory Ruby On Rails Installation and Demo
-Demo App
Nominations:

Roberto and Juan Carlos and Gabriela for their great planning of the future tasks.

martes, 27 de marzo de 2012

Demo Web App with Ruby on Rails

This week I was appointed with the task of doing a web interface in order to distribute the tasks between the nodes of a cluster. And to do this, Ruby on Rails was recommended. So here, I'll explain a short example that I did based on a tutorial. But first, the installation.

Installing Ruby On Rails


Now I'm not planning to go on a lot of details with the installation, because it took me a while to figure out how to fix some errors that I kept getting at the installation. But I'll explain the steps in short. These steps can be found here: http://rubyonrails.org/download anyway if you don't want to read them here again(but with a little more explanation).

1. Install Ruby if you don't have it already

You can download the source and compile it manually. The source can be downloaded from here(Ruby 1.8.3).

Decompress it, move to the decompressed folder, and to compile it run the following command:
  $ ./configure && make && sudo make install

Wait until it finishes.

2. Install RubyGems

As the Ruby on Rails describes, "RubyGems is the standard Ruby package manager.". To install it, we can download the source from here.

Again, decompress it, move to the folder and to install it run the command:
  $ ruby setup.rb
(You'll probably need to be with sudo/root privileges)

3. Install Rails

To install Rails, you can just use gem to install rails and all its dependencies using the command:
  $ gem install rails
Note: This command will show no sign of activity at the beginning(which I misinterpreted as the command not working, so I kept cancelling it). To check what its actually happening, add a -V flag to the command to force the install to verbose output.
  $ gem install rails -V

4. Make a new App

If everything was installed correctly, it is the time to make a new application. To do this we can just use the following command:
  $ rails new appname
This will create all the necessary files and directories that you'll need to create your application. Now we can build our gems (packages) that we're going to use in the application. We can check them in the Gemfile in our appname/ directory. To build the gems, just use the command:

  $ bundle installDemo App

Now, to test the web interface, first we'll need to start the server. To do this, just move into the application folder and run the following command:
  $ rails server
Now we can check on our favorite browser, the address http://localhost:3000/.

Demo App

I found this tutorial pretty good for starting with ruby on rails. It shows the way to create resources using the scaffold command and giving some parameters to the command as well. I imagine this resources/models as objects, because you can give them attributes of what you want them to have. 

The example there on the tutorial is an user resource. So if we want to in fact, create an user, that user should contain the following attributes:
The scaffold command should contain the following:
$ rails generate scaffold User name:string email:string
The id is automatically added, so it is not necessary to define it. 

This would generate an users data model that will be stored in the database. To access it, we'll need to update the database using the command migrate, like the following:
$ bundle exec rake db:migrate
Doing this, will add some functionality to the web page. We'll be able to see all the registered users, add new users, and edit already existing users. Each of these functions are in the directions:
URLActionPurpose
/usersindexpage to list all users
/users/1showpage to show user with id 1
/users/newnewpage to make a new user
/users/1/editeditpage to edit user with id 1




Here are some screen captures of the web app.

Now this is cool, but this will not provide any kind of validation in the input, so how would we add some validation or other personal codification to the web app. To do this, we can modify the user.rb file located in the appname/app/models directory. Here we can write code (In Ruby, or Rails), to do what we please with the data models. For example, lets do a validation to the input at the user's email making it shorter than 30 characters, and longer than 10. To do that we can make the following changes to the appname/app/models/user.rb file.

class User < ActiveRecord::Base
validates :email, :length => { :maximum => 30, :minimum => 10}

end

Now, if we try to input an email shorter than 10 characters, the web app should produce the following error:


And if we try to input an email larger than 30 characters, the following error should be produced:

And this is the end of an easy app. This doesn't mean that this is all of ruby on rails. Obviously this is just the basics, and ruby on rails has a lot more to offer to help in creating a better web app.

References:

domingo, 25 de marzo de 2012

Proyecto de Dispositivos Móviles

En este post, realizaré reportes semanales de mi avance.

Semana 1:
Selección del proyecto - Sistema de Pánico

En la primera semana, me dedique exclusivamente a seleccionar la aplicación que desarrollaría durante el semestre, me decidi por el sistema de pánico. La idea del sistema es ser usado en momentos de emergencias, para que el celular haga llamadas, o mande mensajes de emergencia en el menor tiempo posible.

Semana 2:
Instalación de Herramientas:

Durante la segunda semana, instalé el Android SDK tanto para Windows como para Ubuntu, para comenzar a probar las funcionalidades con las que cuenta. En esto tuve problemas ya que inicialmente no podía instalarlo, y se me presentaban problemas que en la guía de instalación no mencionaba.

No obstante, buscando en internet logre resolverlos, solamente para que mi memoria en la que corría Ubuntu fallara y dejara de funcionar. 

Formatee la memoria y le volví a instalar Ubuntu para poder seguir de nuevo los pasos que ahora ya sabía, y ya no tuve problemas.

Hice pequeñas pruebas en el HelloWorld que tenía por default solo para probar que todo funcionara correctamente.


Los post que realicé esta semana sobre el proyecto fueron los siguientes:
Semana 3:
No hubo avances.


Semana 4: 


Investigación sobre las capacidades de los dispositivos móviles actuales, en comparación con las computadoras y laptops.

Para esta semana, me di la tarea de investigar un poco sobre las especificaciones de los mejores dispositivos móviles actuales, como el Samsung Galaxy S 2, y para conocer que tanto han avanzado, realicé una comparación con una computadora Alienware, con partes muy potentes. Esto fue para conocer que tanto se acercan los celulares en cuanto a poder de procesamiento a las computadoras, no para decidir cual comprar, o realizar comparaciones directas de que es mejor, ya que cada aparato esta dirigido a funciones distintas, y este tipo de comparación no tendría sentido.

El post que hice esta semana fue el siguiente:


 Semana 5: 
Investigación sobre la conectividad, y los tipos de conectividad en los dispositivos móviles


La semana 5, investigue sobre la conectividad en los dispositivos móviles, su funcionamiento, alcance y  demás. 
El post que hice esta semana es:

Semana 6:


Investigación sobre la API de Android


Esta semana investigue en la API de Android clases importantes que me podrían servir cuando realice mi proyecto. En esta investigación encontré clases interesantes como la DataBase, Location, GSM y una clase de android especializada en realiar pruebas.

El post de esta investigación es el siguiente:

Semana 7:
Investigación sobre los Sistemas Operativos Móviles

Durante la semana 7 investigué los sistemas operativos móviles más importantes y sus características. Los sistemas que investigue fueron, Symbian OS, iOS, Android, Windows Phone y Palm OS. La idea de esta investigación fue conocer los sistemas operativos disponibles, y las características con las que cuentan unos y otros.

El post de esta investigación es el siguiente:
Semana 8: 
Investigación sobre la batería en los dispositivos móviles

En la semana 8, me dedique a investigar el funcionamiento y algunos tipos de batería que contienen los dispositivos móviles de hoy en día. También investigue sobre los mejores, para hacer comparaciones de cuanto pueden durar, en tiempo de llamadas, y reproducción de video para poder darnos una idea de la duración de la batería.

El post de esta investigación es el siguiente:

Reporte de Avance - Medio Curso

A continuación mostrare los avances correspondientes a mi proyecto de la materia de dispositivos móviles. 


Presentación:




Importancia/Impacto esperado del Proyecto

Inicialmente, mi idea del proyecto fue la siguiente: "Una aplicación con funciones esenciales para llamadas de emergencia". Esto involucraría llamar al número de emergencias simplemente con un solo botón, o seleccionarlo de una lista. La idea evolucionó poco a poco al ver otras aplicaciones que eran similares, es decir, aplicaciones que enviaban mensajes, que guardaban información esencial sobre la salud del usuario, y otras más. 

Al investigarlas me di cuenta que en sí, no hay ninguna aplicación que reúna todas las funcionalidades en un solo sistema. Además de reunirlas, es un reto también hacer que la conjunción de estas en un mismo sistema no cause problemas de tiempo, es decir que todas puedan ser accedidas en el mismo tiempo (menor tiempo posible desde abrir la aplicación).

Agregando a esto esta la funcionalidad GPS, si bien tenía pensado tener hospitales y estaciones de policía asociados a direcciones y entonces encontrar el más cercano, esto sería muy tedioso, por lo tanto me dedicaré a simplificar la idea a el número de emergencias del área, que usualmente varía por países, esto incrementaría enormemente el impacto del proyecto, ya que lo haría internacional

Además tengo pensado hacer la aplicación en inglés y español, para poderla hacer así entendible a un público más grande, pero aún así colocando imágenes a cada opción en lo posible, para poder explicar claramente que funcionalidad hace.

Me parece que todos estos elementos hacen que mi aplicación (o por lo menos la idea de la aplicación, por el momento) pueda tener un impacto importante en la sociedad.


Herramientas y Tecnologías Utilizadas


Android




En un post anterior, había mencionado que escogí Android como plataforma para programar la aplicación, pero no fui muy claro en por qué lo escogí sobre otras tecnologías como: iOS, WindowsPhone y demás. 

Mi razón de escoger Android es por la cantidad de personas que utilizan smartphones con el sistema operativo Android, que en comparación con las personas que tienen iPhones o smartphones con Windows Phone, son mucho mayores. Esto le daría a mi aplicación una proyección mayor.

Además, mi deseo es que mi aplicación esté disponible a la mayor cantidad de público posible, y de nuevo, los celulares con Android son los que mayor ventas tienen en estos días, ya sean Nokia, Motorola, Samsung, LG, etc.


Eclipse

Android se integra bien con eclipse, y esto me puede ayudar a facilitar muchas cosas como el debug, y el correr mi aplicación en el emulador para realizar pruebas.


También tiene herramientas para editar el xml y definir una interfaz de usuario.


DroidDraw

Un programa que encontré. Funciona ya sea en línea, o stand alone descargándolo en Windows, Linux o Mac OS. Funciona con una simple interfaz para ir agregando widgets y layouts a un área, lo que podemos usar para generar nuestra interfaz como deseemos. Ya teniendo dicha interfaz, es posible generar el xml basado en ella, el cual podríamos importar a nuestro proyecto.


Calendarización


Primero que nada, el trabajo que he hecho hasta la fecha puede ser verificado en el post especialmente dedicado al proyecto.


Ahora, el diagrama de la calendarización es el siguiente:



(Click para ver en tamaño completo)
Explicación


Lo que pienso hacer en un futuro cercano es primeramente, terminar de investigar sobre los GPS, las bases de datos y el funcionamiento de las clases de Android especializadas en llamadas y mensajería. Ya conociendo un poco sobre todo esto (por lo menos lo suficiente para saber buscar más adelante cuando sea necesario), avanzaría al diseño de la interfaz en sí, lejos de los prototipos o ideas que tenía inicialmente. 

Me gusta comenzar por la interfaz, ya que al tener la idea de donde quedan los botones, formularios y demás, lo siguiente es simplemente relacionarlos con las acciones que harán, y estas con las clases que realizan dichas acciones. Además el hecho de que la interfaz se pueda realizar desde un xml, separando la interfaz del código de cierta forma, me parece que lo hace mucho más simple y limpio. Esto tengo pensado hacerlo en una sola semana, obviamente no dedicándole todos los días(hay otros proyectos que también debo avanzar), es probable que no tome mucho tiempo teniendo diseños ya en mente.

Lo siguiente sería ya entrar de lleno a la programación, primeramente quiero que funcionen las llamadas y mensajes, por esto antes quiero investigar, ya que no estoy seguro si es posible hacer pruebas a esto desde el emulador, o si es necesario un dispositivo. Teniendo esto, considero que sería un 60 -70 % del proyecto.

La parte final sería la base de datos, y su función con el GPS. Como mencioné, tuve que degradar esta idea para hacer la aplicación mucho más usable en un mayor número de países posible. La idea actual es que llame al número de emergencia del país correspondiente, el cual detectará el GPS. Para esto entonces, necesitamos tener una base de datos con países, coordenadas quizás, teléfonos y otra información para que la aplicación sepa a que número marcar.

Ya para terminar, se harían pruebas en un dispositivo para asegurarnos que funcione correctamente.


Consideraciones de Usabilidad 




La idea de mi proyecto es bastante clara, una aplicación para emergencias. Por lo tanto, no es difícil pensar en algunas consideraciones de usabilidad que debería tener, prácticamente por obligación, para justificar la existencia de la aplicación.
Las consideraciones de usabilidad más importantes son las siguientes:
  • Interfaz Simple. No podemos darle a un usuario una aplicación de emergencias que sea muy difícil de entender, sino que sentido tendría utilizar una aplicación especializada para estos casos, si simplemente podemos buscar el número en nuestro propio celular.





  • Múltiples funciones. Ya existen aplicaciones similares a mi idea, pero el problema de estas es que sus funcionalidades están esparcidas, alguna para llamar a emergencias, otra para mandar mensajes, otra para guardar información sobre la salud, etc. Por esto, mi aplicación debe abarcar todos estos campos, con la misma o mejor eficiencia que estas, sin afectar la simplicidad.



(Imágenes tomadas de: https://play.google.com/store)
Aplicaciones similares
  • Eficiencia(Tiempo). Las personas en casos de emergencia carecen de tiempo, cada segundo es valioso, por lo tanto queremos también disminuir el tiempo gastado desde home o la parte principal del sistema operativo, hasta poder realizar la llamada o función específica para esa emergencia. Esto involucra también que la aplicación debe cargarse rápidamente. La idea podría ser pedirle al usuario que deje que la aplicación coloque un bookmark  en la pantalla home, o algo por el estilo, como lo siguiente:
(Imágen tomada de: https://play.google.com/store)
Simplemente se presionaría el botón, y la aplicación haría lo suyo
  • Lenguaje. Mi idea es realizar la aplicación tanto en inglés como en español ya que, en el mismo proyecto creado por eclipse, se genera un xml llamado strings.xml, donde se almacenan todas las palabras usadas dentro de la aplicación, en los botones, labels, y dempás. Éste xml, puede ser escrito en diferentes idiomas, y almacenado en una carpeta diferente para cada idioma, entonces la aplicación accedería al xml adecuado para el lenguaje en el que esta configurado su celular. Si está en otro idioma diferente al inglés y al español, se cargaría el inglés.
(Imágen tomada de: https://play.google.com/store)
Más claro imposible
Referencias:

Usabilidad en los Dispositivos Móviles

La usabilidad en los dispositivos móviles es un tema importante a abordar al momento de desarrollar aplicaciones para ellos. No podemos considerar los mismos puntos que pensaríamos para una laptop o una PC, por razones simples como el tamaño de la pantalla, el contexto(las laptops y PC no son tan portables como un celular) y las especificaciones. 

En este post hablaré sobre los detalles de usabilidad que debemos tomar en cuenta, y algunos métodos para probar la usabilidad de nuestra aplicación móvil.

¿Qué es la Usabilidad?

La usabilidad es la facilidad con que las personas pueden utilizar una herramienta particular o cualquier otro objeto fabricado por humanos con el fin de alcanzar un objetivo concreto. En nuestro caso, nos referimos a la usabilidad como la claridad y la elegancia con que se diseña la interacción con un programa o un sitio web. 


Los tres componentes de la usabilidad

El modelo conceptual de la usabilidad, proveniente del diseño centrado en el usuario, no está completo sin la idea utilidad. En inglés, utilidad + usabilidad es lo que se conoce como usefulness.

Jackob Nielsen definió la usabilidad como el atributo de calidad que mide lo fáciles que son de usar las interfaces Web.

Usabilidad en Dispositivos Móviles

Los dispositivos móviles presentan varios problemas únicos en adición a los problemas de usabilidad normales que tienen los diseñadores. Los problemas asociados con los dispositivos móviles, suelen ser en función de los dispositivos: pequeños, con pantallas de poca resolución, opciones limitadas de entrada (no tienen mouse, o teclado completo), hardware lento(últimamente esto ya no es problema), y en algunos casos, conectividad poco fiable.

Diseño del Dispositivo

La mayoría de las limitaciones que debemos tomar en cuenta cuando diseñamos y desarrollamos aplicaciones móviles, normalmente refieren a la interfaz física del dispositivo. Entonces el tipo de dispositivo en el cual la aplicación correrá es una consideración mayor de diseño. Un buen aspecto al diseñar una aplicación, por ejemplo para el iPhone, es que la forma del dispositivo y su interfaz física son estandarizados. 

Pero al diseñar aplicaciones para otras marcas de dispositivos móviles, tenemos que lidiar con la variabilidad significante en sus tamaños de pantalla, formas, e interfaces físicas. Por ejemplo, los teléfonos Blackberry pueden tener pequeñas pantallas con un teclado QWERTY físico de teclas pequeñas como el Blackberry Curve, o puede tener una pantalla touchscreen grande y un teclado virtual como el Blackberry Storm. 

Consecuentemente, la interacción con los diseños de estos dispositivos debe ser significativamente diferente. El Blackberry Storm requiere grandes botones para facilitar la interacción con la pantalla touchscreen, mientras que el Curve requiere elementos de navegación pequeños para que puedan caber en la pequeña pantalla. Por esta razón, es necesario especificar los dispositivos móviles en los que se pretende que la aplicación corra, al momento de definir los requerimientos.


Blackberry Curve (Izquierda) y Blackberry Storm(Derecha)

Contexto

Es esencial reconocer que los usuarios no estarán sentados en un escritorio y viendo a una enorme pantalla por una gran cantidad de tiempo, en un ambiente pacífico. En su lugar, los usuarios serán móviles, quizás caminando por la calle, manejando un automóvil(no recomendado), sentados en un camión, o esperando en un restaurante, es decir, es muy probable que la aplicación sea usada en lugares rodeados de personas y otros estímulos. 

Entonces, en vez de estar siendo ejecutada en una oficina tranquila, la aplicación debe competir con incontables estímulos como el constante movimiento de las personas y vehículos alrededor de el usuario, además de las interacciones con otras personas. También, ya que la aplicación corre en una pantalla pequeña, cuenta con un impacto visual menor, y es más difícil atraer la atención a los usuarios que con una computadora o laptop.


Rapidez

Es por estos puntos que es importante que los usuarios sean capaces de abrir la aplicación rápido, lograr lo que desean cumplir en la aplicación, y salir rápido para regresar a sus tareas en el mundo exterior. Lograr este tipo de acciones rápidas es esencial para el éxito de una aplicación de dispositivos móviles.

Atención

En un ambiente de la vida real, una aplicación real debe superar la competición por la atención de un usuario, lo que va mucho más lejos que simplemente superar la atención sobre una aplicación similar a la nuestra. Por ejemplo, si nosotros desarrollamos una aplicación que muestre noticias, es importante considerar por qué un usuario usaría nuestra aplicación en vez de simplemente comprar el periódico. 

Las aplicaciones de navegación han hecho un gran trabajo en competir por la atención de los usuarios. Su competición incluye mapas tradicionales, direcciones impresas, y dispositivos de navegación dedicados(GPS). Los mapas tradicionales no permiten el seguimiento de una posición vuelta por vuelta, las direcciones impresas no permiten información de la posición actual tampoco, por lo tanto no son útiles si damos una vuelta incorrecta, y los GPS no incorporan otras funcionalidades como hacer llamadas, checar correo o escuchar música. 

Una aplicación de navegación móvil ofrece ventajas significativas sobre cada una de las competencias que logran el mismo objetivo. La aplicación móvil debe ofrecer ventajas similares para ayudar a asegurar el éxito. 

Uso con una sola Mano

También es importante notar que los usuarios pueden estar realizando actividades simultáneas que no solo requieren su atención, pero también pueden tomar el uso de una mano. Por ejemplo si una persona esta cargando una bolsa con una mano, y usando una aplicación móvil en su celular con la otra, la persona puede descubrir que no es posible usar dicha aplicación en ese caso, lo que puede impedir que la usen hasta que tengan total atención en ella. 

Por lo tanto, la operación de las aplicaciones usando una sola mano es una consideración mayor para las aplicaciones móviles.



Impacto de la baja resolución

Comparado con los usuarios de computadoras de escritorio, los usuarios de dispositivos móviles pasan más tiempo buscando información que el tiempo que gastan navegando en internet. Por esto se dan las siguientes recomendaciones de diseño:
  • Minimizar la cantidad de scroll necesario para encontrar información
  • Incluir más opciones de búsqueda

Impacto de la velocidad de descarga

Normalmente, las aplicaciones para dispositivos móviles son diseñadas sin la preocupación de los ambientes en donde se usarán. Estos ambientes suelen ser incontrolados e involucran más distracciones que un típico ambiente de escritorio.

Por esto se sugiere la implementación de mecanismos de retroalimentación táctiles que notifiquen a los usuarios si la tarea se espera que termine en más de cuatro segundos. Esta retroalimentación permitiría a los usuarios dirigir su atención de vuelta a lo que este haciendo, en vez de tener que voltear cada momento a checar el estado de la pantalla. Esto reduce la cantidad de miradas necesarias al dispositivo, e incrementa la seguridad del usuario.)

Referencias: