Firefox 4: mi feedback

Técnicamente no puedo opinar demasiado sobre el Firefox 4 en su versión Beta. Puedo decir que es rapidísimo. De sus otras ventajas aún no he podido disfrutar.

Pero quiero opinar sobre la experiencia como usuaria en el siguiente escenario:

1. Cuando yo toco el botón derecho del mouse en los navegadores que uso (Firefox 3.6, Iceweasel, Epiphany) la opción que aparece de primero es abrir el enlace sustituyendo la página actual y en segundo lugar, abrir el enlace en otra pestaña. La opción de abrir en otra ventana aparece en tercer lugar. En Firefox 4, se ha eliminado la opción 1 y eso hace que continuamente abra una nueva ventana en lugar de una nueva pestaña.

2. Me dirijo entonces a hacer lo que se supone es mi contribución como usuaria: opinar sobre eso para que el equipo desarrollador valore si debe cambiar o no. ¿Cómo hacerlo? Ni idea.

3. Acudo al menú que dice “Help” y me encuentro con una opción que dice “Submit Feedback”. En mi experiencia, enviar retroalimentación es decir qué me parece algo y eso puede se tanto para agradecer o felicitar, como para reportar algo como lo del menú ligado al botón derecho ¿no?

4. El problema, es que cuando pulso para dar retroalimentación aparece una página con este mensaje:

y un espacio de una línea donde caben 140 caracteres. ¡140 caracteres para dar mi mensaje!. Probemos:

Menú botón derecho eliminaron opción 1 confunde usuario abre ventana nueva molesto

me quedan 58 caracteres… pero no es suficiente para que yo tenga una experiencia agradable y sienta que mi retroalimentación es bienvenida. ¿Debería serlo? Tal vez no. Puede que sea un caso de una usuaria equivocando la función de la opción de “send feedback”.

Pero me quedan muchas dudas: ¿por qué el feedback debería ser triste? ¿quién dice que he tenido una mala experiencia con mi navegador? ¿por qué culpabilizar a la persona usuaria y hacer que se arrepienta de comunicarse con quienes pueden mejorar su navegador?

Me encantaría sugerir cosas a quienes se ocupen de eso en Mozilla. De verdad. Creo que es parte de lo que debemos mejorar en todos los proyectos de desarrollo. Necesitamos que las personas usuarias sientan la diferencia entre ser usadas por su software y usar un software que responde a sus necesidades.

¿Qué tal algo como esto?

(ninguna cara, ni feliz ni triste…)

El equipo que construye tu navegador estará agradecido de recibir tus comentarios. Queremos mejorar tu experiencia. Por favor envíanos tu reporte.

Acompañado de una encuesta muy básica que permita reportar algo de forma ágil, útil y esperanzadora. *** Por cierto, el mensaje en inglés es peor que en español porque dice “nuestro navegador” y no “tu navegador” como debería ser.

Ojalá este mensaje llegue a alguien que pueda tocar la puerta correcta en Mozilla. Tal vez, este feedback les sea útil.

PD: Aprovecho para recomendar Limesurvey para las encuestas. Es libre, excelente y mucho mejor que los formularios comunes. El formulario acerca de cuántos navegadores uso y otros temas, no ocultaba las preguntas que no me correspondía responder a partir de las respuestas ya dadas. Eso con Limesurvey sería mucho más elegante y agradable.

Lo bugs que sí y los bugs que no

Leí un correo de Ian Jackson en el que se refería específicamente al error de pensar que todas las personas pueden y deben reportar bugs. Me gustaría traducirlo completo pero ahora mismo no puedo. En resumen, más o menos planteaba -con más sinceridad de la que mucha gente agradece- que para el caso de Debian, si un desarrollador debe gastar dos de sus cuatro horas diarias de programación para responderle a personas usuarias que reportan bugs que en su mayoría, son errores de procedimiento… eso no es beneficioso para el proyecto debian. Para él, “mimar” a las personas usuarias de esa manera no contribuye en nada. Habla de varias falacias muy interesantes y si leen inglés, por favor revisen el correo antes de seguir leyendo aquí (que mi resumen es muy pobre, la verdad).

Aunque puede parecer chocante… la verdad sea dicha: tiene razón. Tiene razón cuando hablamos de proyectos de desarrollo de un sistema operativo o aplicaciones horizontales. Todos los desarrolladores saben cómo debe comportarse un sistema operativo. Es decir, en la mayoría de los casos, los reportes no le dirán nada nuevo y si no los hacen personas con suficientes conocimientos, no contribuirán en mucho a encontrar la solución. –> Hace un año me hubiera pegado por la mano por escribir una cosa así.

¿En dónde sí vale la pena reportar bugs?

No sé… imagino que en desarrollos como Gimp o aplicaciones para sectores u ocupaciones específicas. Ahí sí los desarrolladores no saben qué es lo que se espera del programa (supongo) y ¿se necesita de mucha guía de personas usuarias que sí saben qué es lo que el programa debe hacer o cómo, lo que imaginan, no puede ser implementado a partir de la herramienta?

¿Y entonces, cómo mejoramos el software?

También, es importante reportar el otro tipo de bugs… los bugs generados por la endogamia hacker: ¿qué cosas no son útiles a las personas usuarias? Habría que generar espacios distintos, algo como grupos focales que permitan recibir observaciones sobre cosas que no se reciben bien, errores comunes en una interfaz, campañas equivocadas o actitudes que nos alejan de los proyectos. Es decir, por mucho tiempo las personas que no programamos, hemos pensado que debemos convertirnos en lo que no somos, para poder reportar bugs y ayudar “de verdad”. Tal vez la pista esté en otro tipo de reportes que debemos hacer e incluso, en no reportar nada más, sino involucrarnos de lleno en organizar el cambio. Y ahí es donde topamos con pared: ¿en cuáles espacios podemos mejorar el software quienes no programamos? ¿tenemos que conformarnos con probar versiones nuevas de los programas? ¿tenemos que dedicar nuestra energía a aprender a reportar bugs apropiadamente en lugar de aprovechar las capacidades que ya tenemos?

Para nada de eso tengo respuesta. Yo sólo tengo dudas.

—————————-

Lamentablemente, este post tuve que rescatarlo del cache. Desapareció, seguramente por torpeza mía y se perdieron entonces los comentarios de Gunnar Wolf :-(

A desalambrar el software libre

defences

Imagen: Defences become fences N°2, de Enrique T

Para actualizar y ser justa: ya casi estamos terminando la traducción de la campaña http://windows7sins.org gracias a la ayuda de Gabriel Molina, un mexicano con el que he podido trabajar en conjunto superando la barrera del repositorio. Gabriel accedió a trabajar “a pie” y hemos revisado juntos todos los textos. Gracias Gabriel.

Constantemente digo en mis conferencias, que no hace falta ser experto para ser parte del desarrollo del software. Es decir, si no sabemos programar, los usuarios y usuarias podemos dejar de ser entes pasivos y convertirnos en gestores del software, colaborando en actividades de difusión y activismo, pero también traduciendo, documentando y reportando bugs. Son tareas menospreciadas, pero bien importantes.

Lo lamentable, es que eso es falso en la mayoría de los casos. Los proyectos de software libre siguen siendo espacios pensados por y para informáticos, quienes muchas veces piensan que es relativamente simple seguir su lógica. Les tengo una mala noticia: NO LO ES.

La primera y única vez que reporté un bug, lo hice a la gente de KDE por un problema con el Aamarok 2. Me respondieron más o menos, que si no sabía reportar un bug correctamente, mejor los dejara en paz. Nunca más reporté un bug en mi vida (al menos, directamente) y me quedé con el Amarok anterior. Yo quisiera, lo juro, poder reportar un bug de una manera tan hermosa como esta (vía magus) pero es imposible para mis capacidades. De manera que los bugs quedan descartados, bajo la premisa de “lo que no sirve, que no estorbe”. Ok. Puedo vivir con eso.

Si no puedo reportar bugs, puedo traducir… ¿cierto?

Puedo traducir con enorme felicidad y satisfacción si lo hago para Drupal. El sistema que usan es en línea y es sencillo, maravillosamente sencillo colaborar. En los translation sprint que hemos organizado en la RCSL llevamos dos módulos completos traducidos al español, en un trabajo que ha sido divertido y enriquecedor. Jamás frustrante.

En otro vecindario, la traducción de la campaña Windows7sins de la Free Software Foundation, no me ha traído más que tristezas. Desde hace dos meses tenemos los textos traducidos y revisados por tres personas, pero se decidió usar subversion, pedir llave pública, entrar por ssh y de ahí, ya no sé qué sigue. El caso es que los textos los tradujimos al mejor estilo cavernícola (con openoffice.org) y ahora tocaría meter línea por línea dentro de los archivos html que hay en savannah. Si hubiéramos tenido archivos .po ya todo estaría listo… tampoco estoy pidiendo milagros… pero con este sistema ha sido imposible para Eva y para mí -las que más nos hemos comprometido con el asunto- de manera que la campaña sigue sin estar traducida al español, y así seguirá hasta que alguien pueda hacerlo y se publique otra traducción no revisada. ¿Nuestro trabajo qué? Bien gracias, guárdemoslo de recuerdo.

Entonces… ¿cuál es la verdadera posibilidad que tenemos los y las usuarias de software libre, de convertirnos en gestores y gestoras del cambio? ¿cuál es nuestro papel, más allá de dar conferencias, vender camisetas o escribir en un blog? Dar conferencias no debe subestimarse, porque implica conocer bien los temas, estar preparada para responder muchas preguntas diversas y saber exponer claramente conceptos complejos… pero eso no basta. Sobre todo, cuando interactuamos con proyectos de desarrollo donde lo que vale es el código y no cuántas personas escucharon una charla e instalaron software libre después.

Yo, de todas maneras aprecio mis contribuciones y creo que son bien importantes, pero definitivamente creo que tenemos que hacer un mejor trabajo si queremos realmente trabajar por la libertad de los usuarios y usuarias. Ni todos somos poetas, ni todos somos programadores. Tendríamos que generar espacios y niveles de acción, que permitan que más personas se acerquen y hagan tareas que son capaces de hacer. Muchas podemos traducir, pero por favor, quítennos los alambres de púas.