HCI: hacer que el usuario espere a través de todo el frente, o amortizar?

Question

Estoy escribiendo una aplicación de Silverlight que consulta un servicio web para rellenar un control de árbol. Cada elemento tendrá al menos 2 niveles de los niños, así que algo como esto:

a
+-b
  +-c
d
+-g
  +-h
e
+-i
  +-j
f
+-k
  +-l

La API de servicio web es tal que sólo puedo conseguir un nivel de nodos secundarios a la vez, por lo que el primer viaje, puedo conseguir a, d, e, f. Para obtener b, g, i, k, tengo que hacer 4 viajes. Del mismo modo, tengo que hacer 4 viajes más para obtener c, h, j, l. (El servicio tiene realmente me permite obtener todos los nodos en un solo viaje, pero no me da las relaciones entre padres e hijos junto con él: - ()

Mi pregunta es la siguiente: ¿debo hacer que el usuario espere durante un tiempo en la delantera, mientras que consigo todos los nodos de la vista de árbol, o debería obtener sólo la parte superior unos nodos, y obtener los demás nodos de la carta, o en una tarea en segundo plano? Además, los nodos pueden cambiar de forma asíncrona, por lo que si consigo todos los nodos en la delantera, necesitaré un botón "Actualizar" para la vista de árbol, y si lo hago en la demanda, voy a tener que tener una estrategia de almacenamiento en caché.

Lo que es mejor para el usuario?

Answer 1

Un compromiso donde se carga el primer nivel por adelantado y luego cargar los productos que queden en el fondo anulado por bajo demanda según sea necesario. Si carga los nodos amplitud primero (por ejemplo, a, d, e, f entonces b, g, i, k) en lugar de profundidad primero (por ejemplo, a, d, e, f seguido por b, c) se puede redirigir su carga hasta centrarse en el nodo más recientemente ampliado.

Answer 2

En lo personal, como usuario, preferiría todos los datos que se cargarán en la delantera por lo que una vez que la aplicación termina de cargar puedo confiar en que no voy a tener que esperar más (o al menos muy poco)

Sin embargo, supongo que depende de varios rasgos de su aplicación / datos:

• ¿Cómo dinámica son los datos? Tampoco actualiza con mayor frecuencia que la velocidad a la cual el usuario explora los nodos? Si lo hace, entonces usted tendrá que leer los datos que el usuario explora, de lo contrario es probable que pueda salirse con la única la actualización de vez en cuando y la comprobación de los datos más frescos antes de realizar operaciones importantes.
• ¿Qué parte de los datos que el usuario va a explorar durante el uso normal? si están constantemente explorando a lo largo de todo el árbol, y luego tener todo el árbol cargado es importante. Por otro lado, si la mayoría de los usuarios por lo general sólo expandir una pequeña porción del árbol, entonces tal vez la carga de la demanda es mejor para que no pierda el tiempo de carga de datos emabrgo nunca verán de todos modos.
• ¿Cuánto afectará con este tener en el rendimiento? Realmente toma mucho tiempo para cargar todos los datos? Si los datos no es demasiado, puede que todo el asunto se puede cargar en cuestión de segundos, en cuyo caso la cantidad de trabajo a implementar la optimización no será significativo para el usuario final y, a su vez, no tendrá un buen retorno de la inversión.

Lo más probable es que usted no tiene respuestas bien claras a estas preguntas, pero es probablemente bueno tener en cuenta cuando se está atacando este interesante problema.

Answer 3

Respuesta corta es hacer que la espera de usuario para tan poco como sea posible. Maldecirán su nombre si tienen que esperar 10-20 segundos en la carga de aplicaciones, pero no se dé cuenta de 0,1-0,2 segundos para que un nodo del árbol se expanda.

Tengo una aplicación en la producción con una estructura similar. No se puede cargar por adelantado porque sería cargar con eficacia toda la base de datos. Aquí está mi estrategia:

• El control de árbol comienza con 1 nivel ampliado por debajo de la raíz.
• Cada nodo no expandido tiene un nodo hijo ficticio con el fin de obtener el [+] icono de expansión para mostrar
• Cuando se expande un nodo, se dispara un evento que está atrapado por la aplicación. Si el único nodo hijo es un maniquí, se elimina el maniquí y los niños se cargan desde la base de datos.
• Los cambios en los datos no se reflejan automáticamente por nodos visibles, sin embargo el menú contextual para el árbol tiene un elemento de actualización que se puede utilizar para actualizar un nodo.

He considerado que muestra las actualizaciones de forma asíncrona, pero han tendido a evitar que debido a que grandes cantidades de datos se pueden mostrar en el árbol y yo soy cuidadoso de la carga DB si todos ellos estoy comprobando los cambios.

La aplicación se WinForms, escrito en C # usando .NET 2.0.