Iván, estoy de acuerdo en que formulario único es mejor cuando se
trata de procesos en batch, es decir, cuando tienes a personal
administrativo que trabaja como "grabador de datos", rellenando los
mismos campos una vez tras otra.
Sin embargo coincido con Juan Leal en que para procesos que se van a
abordar pocas o una sola vez (ej. poner una casa en venta), hay que
tener en cuenta ciertas premisas:
- cuantos más datos pidas por pantalla, más probable es que se
produzca un error o se olvide un campo
- formularios muy grandes disuaden a usuarios "voluntarios" que pueden
evitarselo (por oposición a los "grabadores de datos", que se lo saben
de memoria)
- en algunos casos puedes permitir que dejen el proceso a medias y lo
retomen más tarde, pues ya tienes parte de la información
- puedes contextualizar más cada bloque de preguntas y añadir
previsibilidad ("en el próximo paso le pediremos los datos de su
tarjeta, procure tenerla a mano").
En una ocasión diseñé un proceso algo exigente donde el usuario iba
completando datos que luego quizás volviera a editar. Al hacerlo por
pasos pudimos asociar un color a cada bloque de preguntas. Para los
usuarios era mucho más fácil recuperar la información después gracias
a ese código de color "esto lo contesté en la parte verde, luego lo
busco en la parte verde".
En resumen, creo que para procesos donde el usuario es novato es mejor
secuenciar en pasos y para procesos repetitivos mejor facilitar que se
rellene en batch.
un saludo.
javier.
On 4/18/06, Juan Leal <[EMAIL PROTECTED]> wrote:
> Qué tal Iván,
>
> Trabajo como Responsable de Usabilidad en idealista.com. Como podrás
> entender, no vamos a descrubir aqui, en la lista, las razones que nos
> han llevado ha estructurar nuestros formularios de tal forma. Lo que
> sí te puedo decir es que no está así por acaso.
>
> Los axiomas y conjunto de recomendaciones que existen en relación a
> los formularios para aproximarlos a las necesidades de los usuarios
> sirven como referencias, pero muchas veces (como en nuestro caso) no
> nos valen al 100% y toca saltarse dichos axiomas.
>
> Para nosotros, la mejor solución fue ésta. Un proceso estructurado,
> que indica al usuario en qué nivel de entrada de datos se encuentra,
> que valida lo que ya ha hecho y le indica lo que le queda por hacer.
>
> Intentar hacerlo en una sola página, con la cantidad de datos
> necesarios que existen, asustaría a cualquier usuario ("menuda paliza
> rellenar todo ésto"). Estructurándolo nos hemos dado cuenta de
> facilitamos este proceso y lo acercamos a la necesidad del que vende
> un inmueble.
>
> Lo creas o no, incluso hemos recibido felicitaciones externas por este
> proceso. Aunque, como siempre, todo es mejorable. Siempre.
>
> Mi consejo es que hagas un poco de benchmarking por ahí fuera para ver
> cómo resuelven "los grandes" este tipo de cosas. Te sorprenderás de la
> cantidad de normas y axiomas pre-establecidos que se saltan. Y seguro
> que sus razones tienen.
>
> Ya me contarás,
>
> Un saludo
>
> Juan Leal
>
>
>
> On 4/18/06, Iván Fociños <[EMAIL PROTECTED]> wrote:
> > En webs como idealista.com los formularios se subdividen en varias páginas,
> > me gustaría saber a qué se debe esta forma de trabajar. Actualmente
> > trabajamos en un panel de control en el que realizaremos cerca de 400
> > movimientos al mes por lo que nos conviene mejorar en todos los aspectos
> > (sobre todo usabilidad) para reducir los tiempos de manipulación.
> > Consultando a los que trabajan actualmente con paneles de control todos
> > opinan que tener disponible todo el formulario en una sola página les ayuda
> > a reducir el tiempo.
> >
> >
> >
> > Saludos de Iván Fociños
> >
> > www.hospedaxes.com - Soluciones en Desarrollo Web
> >
> >
> >
> > _______________________________________________
> > altas, bajas y modificaciones:
> > http://www.cadius.org/lista/opciones.html
>
> _______________________________________________
> altas, bajas y modificaciones:
> http://www.cadius.org/lista/opciones.html
>
_______________________________________________
altas, bajas y modificaciones:
http://www.cadius.org/lista/opciones.html
