Por @Wicho — 18 de Enero de 2005

Hace unos días Alvy comentaba lo bien pensado que está MarsEdit, pues es capaz de recuperar tu trabajo no guardado en el caso de un cuelgue o de que se vaya la luz, pero en eso no es sino la excepción que confirma uno de los diez errores más persistentes en el diseño de software que recopila Bruce Tognazzini en The 10 Most Persistent Design Bugs.

Tog los describe en mucho más detalle y ofrece alternativas, pero la lista es:

  1. El Bug de la alimentación.
    Si el ordenador pierde su alimentación por más de unos milisegundos, palmas todo lo que no hayas guardado... y a ver si hay suerte y vuelve a arrancar.

  2. El dock de Mac OS X.
    Hay nueve fallos de diseño en el dock, lo que probablemente sea un récord. Están todos en The Top 9 Reasons the Dock Still Sucks.

  3. Opciones de menú misteriosamente no disponibles.
    Los diseñadores deberían ofrecer al usuario una forma de saber por qué no está disponible una opción de menú y cómo volver a activarla.

  4. Ordenar usando el código ASCII.
    15 de Diciembre 2008 queda antes de 2 de Enero de 1900.

  5. Nombres de los URLs.
    Muchos navegadores no dejan usar espacios y otros caracteres especiales en las direcciones web; los demás hacen cosas equivocadas con ellos.

  6. Trabaja tú por mi.
    El usuario debería poder introducir los datos en el formato que él quiera, no en el que haya decidido el progeamador. ¿Lleva el DNI puntos o no? ¿Pongo guiones entre los dígitos del número de mi tarjeta de crédito?

  7. El nazi de las unidades de disco.
    Desconectar "a las bravas" unidades de disco suele resultar fatal.

  8. Hostilidad en el comercio electrónico.
    Los sitios de comercio electrónico se empeñan en que comprar algo a través de ellos sean tan difícil como es humanamente posible.

  9. Funciones "inteligentes" que no lo son.
    Estas funciones muchas veces toman la decision equivocada.

  10. Cambio de foco sin avisar.
    Esto sucede cuando, por ejemplo, estás escribiendo y de repente salta un diálogo para contarte algo; antes de que te de tiempo a reaccionar puedes haber pulsado intro, y a saber lo que acabas de aceptar. También puede pasar cuando por fin termina de arrancar una aplicación y tu estás haciendo otra cosa.

Tog reconoce que no son necesariamente fatales, pero que dado que como mínimo son irritantes, y que todos han sobrevivido al menos durante cinco años o cinco versiones del producto, ya va siendo hora de librarse de ellos.

El problema es que algunos incluso han sobrevivido a sus desarrolladores originales y ahora parece que las cosas tienen que ser así; en otros casos, los desarrolladores los conocen perfectamente pero simplemente han decidido ignorarlos.

Y por si estos no te parecen suficientes, en The Ask Tog Bug House hay recopilados más de otros 120 "bugs".

Compartir en Flipboard  Compartir en Facebook  Tuitear

10 comentarios

#1 — IgnacioMarcos

Totalmente de acuerdo! cada dos por tres nos encontramos con este tipo de bugs, en particular me siento identificado con el del código ascii, el comercio electrónico, las funciones inteligentes y el cambio de foco.

Como desarollador/usuario me fijo siempre en estas cosas, porque me parece una tomada de pelo cuando me pasan a mi.

Saludos, Ignacio.

#2 — Oscar

Lo de ordenar por el codigo ASCII si se hace bién no tiene por que haber ningún problema, en el caso de la fecha primero se debería ordenar por la variable tipo fecha y una ver ordenados hacer la representación textual.

Los nombres de las URLs si permiten esos caracteres siempre y cuando se ponga su representacion hexadecimal junto un con codigo '%'. El problema es que Internet esta diseñada en un principio para caracteres alfanuméricos de 7 bits.

En cuanto al formato de introducción de datos me suena a que el tio quiere que metamos un campo de texto y que el tio escriba lo que quiera. Vamos, que se pretende que se haga inteligencia artificial para que "5000", o "5.000" o "cinco mil" o "cinco cero cero cero" lo tome como un mismo valor. Es evidente que en este caso es el usuario el que se debe adaptar, incluso el relleno de papeleo en la vida real te ponen casillas donde debes colocar los datos en un formato determinado, y no necesariamente es para su posterior tratamiento informático.

Por el resto de cosas estoy de acuerdo.

#3 — Barbol

joder, esto me revienta

>Ordenar usando el código ASCII.

es muy frecuente, véase google.

#4 — ¡lvaro G. Vicario

Óscar:

Imagino que el tema con los URL no es que tengan que cumplir determinado formato (algo lógico) sino que muchos navegadores no siempre convierten la entrada del usuario en un URL válido. Hacen algunas cosas (añadir el http:// delante) pero otras no.

Lo que sí te voy a discutir rotundamente es el tema de los formatos de los campos. Si tengo que introducir un teléfono no veo por qué no puedo poner "999-99 88 77". Es muy frustrante copiar y pegar para encontrarte "999-99 88". ¿Qué valor de adivinación implica eso? Al programador le cuesta una línea de código eliminar lo que no sean dígitos (siete líneas si es en VisualBasic :)

#5 — Scila

Pues estoy de acuerdo con Oscar. Si cado uno mete los datos en el formato que quiere luego quedan mal registrados en una base de datos y pasan cosas como la de no ordenarse correctamente las fechas. O bien invertir una gran cantidad de tiempo en formalizar esos datos (de forma manual o programandolo para automatizarlo).

En mi anterior empresa el mayor problema era la formalización de datos (bases de datos de restaurantes, cines, teatros...) y os puedo asegurar que no es nada facil solucionarlo, no os podéis imaginar lo retorcida que es la gente, las cosas que se le ocurre meter en los campos de texto.

En algo tan aparentemente sencillo como el telefono hay quien mete prefijo, quien no, hasta el prefijo inernacional con el + y todo, espacio, guiones, si limitas los caracteres para evitar el prefijo internacional no caben los espacios o guiones...

... y ya para la dirección lo flipas!

#6 — Oscar

¡lvaro:

Lo de los teléfonos puede que quitandole todo lo que no sea numérico funcione en la mayoría de los casos (con un sencillo filtro de expresiónes regulares se puede arreglar), sin embargo no siempre todo es de color de rosa: Imaginaté que dejamos un formulario con campos de texto "libres", en ese formulario hay un campo teléfono y un usuario que entra por primera vez y que no maneja muy bién los ordenadores escribe el suguiente texto "00 (+34) 92 476-29-21 extensión 345"... al final si lo hacemos como tu dices queda esta cadena 0034924762921345, cosa que un empleado extranjero de una empresa internacional recibe, y por supuesto, en su trabajo no es requisito imprescindible el saber como es el formato de numeración telefónica de España ni de ningún otro país. Por lo que si quiere ponerse en contacto con el cliente... ¿tu crees que lo conseguiría con el número "filtrado"?

#7 — [cOrchO]

Lo que más me revienta sin lugar a dudas es el cambio de foco >:-[ grrrrrr... me saca de quicio. Sobretodo cuando estás escribiendo, pero también cuando estás leyendo una página y tienes en otro tab otra página y te salta un cuadro de diálogo (y esto me lo hace el Firefox) y te trae al frente esa página ¡dioosssss! como odio eso...

De lo demás, lo soporto más o menos, aunque el de la hostilidad en el comercio electrónico también me tiene bastante hinchadito... ¿habéis comprado en el CorteInglés? ¡Menudo infierno! incluso para unas simples entradas de teatro. Lo sorprendente esgque avance tanto el comercio electrónico...

#8 — ¡lvaro G. Vicario

> Por lo que si quiere ponerse en contacto con el

> cliente... ¿tu crees que lo conseguiría con el

> número "filtrado"?

¿Y si hacemos que el campo no acepte nada que no sea un número, en qué mejora exactamente esta situación?

Yo no digo que el programa tenga que adivinar pero meter un teléfono, un número de tarjeta de crédito o cuenta bancaria o una dirección IP (lo que hacemos el 90% del tiempo) no debería ser tan complicado.

#9 — Oscar

Pues que se pensaría dos veces el meter la extensión cuando ve que no va a quedar reflejada la información como el desea.

Estoy de acuerdo contigo ¡lvaro que en la mayoría de casos se puede lograr filtrar la información siempre y cuando sea atómica (1ª forma normal de las 5 que hay para construir una base de datos). Sin embargo no es factible que el usuario escriba lo que le venga en gana en campos de un dato único y mucho menos en campos donde puede haber distintos datos.

Imaginate que el usuario en vez de meter un número, pulsa una letra; el filtro se cargaría los caracteres que no fuesen números y la información sería inválida mientras que el filtro piensa que es correcto lo que esta haciendo; sin embargo si solo le dejamos meter números desde un principio y que juntos sean de una longitud determinada se ahorrarán muchos errores.

Además, los usuarios deben mentalizarse de que cuando menos posibilidades de error puedan provocar, será mejor tanto para el sistema como para ellos mismos por la cuenta que les trae. Ahora me viene a la memoria los cálculos que hicieron los ingenieros de la nasa y los de la agencia espacial europea, mientras unos lo hacian en millas otros los hacían en kilómetros lo que provocó que una sonda se estrellará en Marte. Lo que implica que si acotamos a que un usuario solo pueda introducir la información de una forma concreta se ahorre en problemas de interpretación, ya sea por sistemas informáticos o por humanos; el caso es que todos manejemos los mismos datos en el mismo formato.

Dios mio, que rollo me ha salido :)

#10 — frank

el top nine esta desactualizado o mal hecho, una de dos