[pyar] Me revisas el capítulo?

[claudio canepa]

CC:>
1. Personalmente, odiaria una app que se la pasa abriendo ventanitas ( me
refiero a mostrar un tooltip en cada cambio de tema)
lo que hace winamp me agrada mucho mas:
   i. cambia el texto del icono en la barra de tareas
   ii. actualiza el texto disponible como tooltip del icono, pero no lo
fuerza a mostrarlo; si a mi me interesa ver que tema, muevo el mouse sobre
el icono y el tooltip me dice.

RA:>
No hay ventana, asi que no puedo hacer eso

Realmente en el escritorio que vos usás los iconos en 'barra de tareas' /
'quick launch bar' / 'lo que sea que se llame en tu entorno' no muestran
tooltips si le metés el mouse arriba ?

Y si no lo hace en forma automatica, no se podria hacer a mano ? Veo que el
app recibe los eventos mclick y rclick sobre el icono, seria lógico pensar
que recibe mouse over.

En todo caso, si esta solución no fuese posible, habria que pensar como
solucionar este problema de robo de atención; *no es menor*.


CC:>
2. En una de esas es que estoy acostumbrado a como se ven las cosas en
windows, pero lo de mover lo que eran botones 'edit' 'delete' a campos
repetidos en la lista no me cierra del todo:

  - es inusual: normalmente las listas tienen datos y los comandos van en el
menu contextual o botones. Si, quizas en otra 'human interfase guidelines'
no sea asi, en windows es raro.

- Ensucia la vista: toda una doble columna repitiendo lo mismo 'edit'
'delete'.

- Y, al haber mucho mas texto en la ventana no seria problematico para no
videntes ?

RA:>
No lo sé bien todavia. Esa es la parte dificil de resolver de la interfaz.
Igual, cambiarlo a otra cosa, o poner dos distintas, son dos horas de
laburo.

Desde un punto de vista 'meta', es importante la consistencia de
comportamiente entre aplicaciones, y quizas esto deberia hacerse explicito
en el texto.
Entonces te va a aparecer el problema de que
  - este app pùede trabajar en diferentes entornos
  - cada entorno tiene sus propias reglas de consistencia ( Apple human
interfase guidelines, gnome guidelines, etc)
  - Ahi podes hacer explicito tu manera de lidiar con el problema; por
ejemplo desarrollo por aproximaciones sucesivas: primero lo haces
consistente con el comportamiento de tu entorno, luego con feedback de
usuarios ver si es necesario cambiar algo.

Otros problemas ?
Bueno veo estos:
3. El acceso desde la barra parece un poco confuso
      - left click te muestra un menú [ apagar | lista de radios]
      - right click muestra [ configurar, acerca de, salir]
      - para agregar una radio hay que ir a configurar, que levanta la
ventana que se discute en el capitulo.

Que tal si
   - left click levanta la ventana del capitulo
   - rclick menu con
         - lista de radios
         - slider de volumen (util cuando cambias de radio)
         - mute
         - salir ( o sea, terminar la app)

4. el menu que aparece con rclick no se va si uno clickea en el escritorio o
en otra app

5. En la ventana de editar si llenas los campos para una nueva radio y
terminas con 'enter' es como si hubieras puesto 'cancel'; lo mas normal
seria que actuara como 'done', o de ultima que ignorara la tecla.

6. Si ponés el url sin 'listen.pls' no funciona (falla el parser) pero no te
avisa

7. Hay varios formatos de radio URL, la app pareceria que solo acepta .pls .
Estaria bueno un tooltip en el campo URL que te de una pista. Y/o que la
validacion te diga explicitamente qué es lo que quiere el campo.

--
claudio
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20100807/dfb2bfee/attachment.html>