2009-03-20 10 views
7

cuanto a que construyen una aplicación web:páginas Web que simplemente páginas demasiada materia

Últimamente, me he encontrado creación de páginas web que son más simples que las que yo solía. Antes, intentaba introducir tanta funcionalidad en una sola página como podía para evitar tener muchas páginas.

Estoy empezando a darme cuenta de que esto solo hacía las cosas mucho más complejas, intrincadas y confusas de lo que debían ser. ¿Por qué no tener más páginas? Creo que la razón por la que estaba haciendo esto fue porque no quería que el usuario tuviera que navegar a otras páginas; solo para tener toda la funcionalidad que necesitaban en una sola página.

Bueno, estas buenas intenciones se convirtieron en una interfaz demasiado confusa para el usuario y un código fuente muy inmanejable. Soy un nuevo desarrollador y estoy tratando de ser muy reflexivo de lo que estoy haciendo para poder mejorar. Si hace una diferencia, estoy desarrollando en ASP.net (aunque estas son probablemente consideraciones para cualquier plataforma).

Mis preguntas son:

  • Am I overthinking estas cosas?
  • ¿Alguien más se ha encontrado haciendo esto?
  • ¿Dónde está el medio feliz?
+0

Gracias, Ronnie, por elegir mi respuesta como la * respuesta. * –

+0

De nada. Era exactamente el tipo de información que estaba buscando. –

Respuesta

5

No hay ningún experto que pueda darle una regla que funcione en todo momento en todo momento. He sido conocido en mi industria durante años por interfaces "fáciles" y hemos ganado importantes cantidades de negocios por ello (así como 5 premios "Best in Class"). También he tenido personas dentro de mi empresa y fuera de ella que me dicen, durante años, que les gusta mi trabajo pero me gustaría que lo "animara" con más gráficos y tal. Lo que siempre me sorprende es la poca conexión que las personas ven entre los dos.

Así que ... algunas reglas de oro:

  1. Una página debe hacer una lo principal.
  2. Una página bien puede tener múltiples enlaces relacionados con lo principal
  3. de menús y el diseño de enlace debe ser consistente a través de las páginas
  4. simple es mejor que el más complejo
  5. páginas deben ser visualmente atractivo y acogedor
  6. Regla 4 es más importante que la regla 5.

Por ejemplo, mi producto proporciona una interfaz que permite a las personas definir las clases y eventos que se mostrarán en un calendario. I podría tener una página que le permite revisar, agregar, actualizar, eliminar y editar las clases. De hecho, en algunas áreas más simples, he utilizado la vista de cuadrícula para permitir que las personas administren todo en una grilla. Sin embargo, las clases tienen demasiada información para hacer esto y aún así seguir las reglas anteriores.

Así,

  1. El idea principal es: "Aquí está una lista de clases para esta ubicación"
  2. Los enlaces son "Agregar nuevo" que se muestra por encima ya la derecha de la cuadrícula, Cambiar y Eliminar son enlaces dentro de cada fila. Esto es consistente en toda la aplicación.
  3. El menú para el sistema como un todo siempre está en la esquina derecha/arriba. Nada más aparece en la página de clase/evento a excepción de los elementos estándar comunes a todas las páginas (un logotipo, un encabezado, un pie de página).
  4. La rejilla está muy bien labrado, pero no hay gráficos espurios (4,5,6)

algunas cosas duran alrededor de interfaces de usuario y el diseño gráfico.

En primer lugar, desarrolle su propia visión y sea coherente en todas las páginas y aplicaciones.

En segundo lugar, no tenga miedo de simplicity.

A continuación, cuando solicite consejos de otros, tenga en cuenta que no desea sus consejos; desea sus impresiones: desea comprender la forma en que perciben la interfaz. El asesoramiento a veces es bueno pero, en la mayoría de los casos, realmente nocivo. En mi experiencia, todos piensan que son expertos en IU.

Cuando realice su prueba de usabilidad en el pasillo (o formal), debe descontar casi todos los consejos en el sentido de que "debe hacer que se diferencie más de". Como verá, se convertirá rápidamente "y que ," "y que," "y la otra ." Si sigues este consejo, terminarás con un desastre debido a la primera regla de diseño de Brittingham: Si todo es importante, nada lo es. (Ahí va: cuando explique por qué no puede hacer que alguien se destaque más, simplemente dígales que "¡viola la primera regla de diseño de Brittingham!")

Espero que esto ayude!

+0

+1 Muy perspicaz e informativo. ¡Gracias! –

3

Golpeó el clavo en la cabeza. Usa el principio de KISS. (Keep It Simple Stupid) He hecho esto en el pasado también y no solo crea una UI horrible, sino que confunde las operaciones que puede hacer en la página debido a que tiene demasiada funcionalidad. A menudo he encontrado en las pruebas que no tenía suficientes controles para ver si el usuario podía realizar una determinada operación en función del estado de los datos.

Es bastante fácil en ASP.Net escribir varias páginas que hacen tareas simples y luego unirlas con Response.Redirect o Server.Transfer. Ahora todo lo que trato de lograr en una página determinada es lo que dicen las especificaciones de diseño. Entonces, si mi página es solo una página de búsqueda, eso es todo lo que doy. Si el usuario desea ver los detalles de un artículo que fue devuelto en la búsqueda, entonces los envío a una página itemDetails.aspx.

+0

Estoy de acuerdo. El único problema que tengo con varias páginas es guardar y recuperar datos de página de una página a otra. Eso puede generar una buena cantidad de ruido de código. ¿Qué haces para evitar eso? –

+0

Dependiendo de la cantidad de datos que tienen que pasar de ida y vuelta, generalmente lo guardo en Sesiones. Si es demasiado, haré un viaje a la base de datos y la buscaré nuevamente. – Eppz

0
  1. Sin
  2. Sí - me
  3. he encontrado el punto medio era utilizar MasterPages, y usarlo de una manera que era familiar para iframes. Que podría tener una gran cantidad de funcionalidades combinadas bien juntas. Hay una manera más interesante de hacer esto con WPF/Silverlight llama Prism
0

La cantidad de funcionalidad en una página por lo general no está determinado por usted, sino por su cliente. Si el cliente exige una sola página para actualizar algunos VeryComplexObject, es probable que termine con una página aspx que tenga un número significativo de líneas. La razón principal es que simplemente tienes muchos manejadores de eventos para todas las acciones en la página.

Si la página es compleja, es asunto de usted. Siempre debe intentar hacer que su archivo de código subyacente sea lo más simple y limpio posible. Algunas sugerencias en esa dirección:

  • Mueva todo el código comercial a otra capa de aplicación.
  • Utilice ObjectDataSource para proporcionar datos a controles enlazados a datos como ListView, GridView, Repeater, ... Delegar la carga de datos en un objeto dedicado evita una gran sobrecarga en su archivo aspx.cs.

Otra sugerencia es utilizar controles de usuario para implementar partes de su página. Por lo general, solo haría esto cuando pueda reutilizar el control del usuario, pero también puede ser de gran ayuda para reducir la complejidad de la página (tanto su archivo de código subyacente como su aspx).

+0

Desde mi punto de vista, los "clientes" no tienen requisitos de diseño específicos. Ellos generalizan y tengo que resolverlo todo. Es por eso que tengo que determinar qué va donde entre las páginas. –

+0

Estoy de acuerdo con Ronnie en este caso, el cliente sabe cuál es su objetivo final, pero es nuestro trabajo hacer que la implementación sea tan simple de usar como sea posible. Una vez dicho esto, la interfaz de usuario a veces necesita ser más compleja, pero todo depende del trabajo que esté realizando y del tipo de persona que lo use. – lexx

+0

En ese caso, primero crearía una maqueta html para su sitio web para mostrarle al cliente cómo se verá. Involúcralos lo antes posible. No desea construir un sitio solo para que su cliente diga: 'eso no es lo que queríamos'. –

1

Has roto un muro que tienen la mayoría de los desarrolladores de software, el que estaba bloqueando tu visión de usabilidad antes. Muchos desarrolladores realmente no piensan en ello y tratan de hacerlo más fácil rellenando la funcionalidad en una ventana, página web o lo que sea.

Una vez que comienza a diseñar el software desde el punto de vista del usuario, es decir, haciéndolo más fácil, varias cosas comienzan a quedar claras. Una es la cuestión del mantenimiento del código, ese código es más manejable para trabajar si no lo rellena todo en una clase gigante o lo que sea que haya estado haciendo. El otro es la usabilidad en sí misma, que comienza a pensar cómo el usuario realmente está utilizando su aplicación a través de la interfaz gráfica. En tercer lugar, se evitan los requisitos o el alcance lento donde se detiene el desarrollo de funcionalidades que el usuario no necesita.

Nosotros, como usuarios, queremos simplicidad, en parte porque no queremos pasar la mayor parte de nuestro tiempo confundiéndonos con una mala interfaz de usuario cuando podemos hacer nuestro trabajo más rápido con una interfaz de usuario sencilla y elegante. Eso hace que para nosotros los desarrolladores de software sea lo correcto, pensar en su diseño en todos los niveles ... eso y las especificaciones siempre mienten.

0

A veces creo que todos somos culpables de olvidarnos de para quién desarrollamos nuestras aplicaciones. No siempre es fácil, como desarrollador, dar un paso atrás y echar un vistazo a su aplicación como lo haría un usuario. Esta es la razón por la que las grandes empresas emplean a cientos de personas para hacer esto por ellos y no siempre lo hacen bien.

La usabilidad es un tema masivo, pero definitivamente es algo que todos los desarrolladores deben tener en cuenta. Me ha llevado mucho tiempo aprender esto, pero al abordar cualquier tarea de desarrollo siempre trato de pensar en cómo mis usuarios van a interactuar con lo que estoy escribiendo. Esto hará una diferencia en todos los niveles de tu desarrollo.

Sugeriría leer Don't Make Me Think by Steve Krug. Este libro no le tomará una edad para leer y presenta algunas ideas fantásticas que pueden ayudarlo a desarrollar aplicaciones que son mucho más fáciles de usar y comprender.

Siempre he pensado que una vez que he pensado en la experiencia del usuario, las decisiones sobre lo que van a hacer mis páginas web y cómo van a interactuar son mucho más fáciles de hacer.

1

totalmente de acuerdo: la mayoría de los intentos de creación de páginas/formas que hacen demasiada han resultado en

  • errores y vuelve a escribir. Se producen problemas al mantener todas las piezas válidas/sincronizadas,
  • gestión excesiva de las expectativas de los usuarios ("Ingresé aquí un número de factura y hago clic en" encontrar persona "pero aparece un mensaje de error. ¿Por qué?") cuando los dos están lógicamente separados. Estas preguntas no pueden surgir si solo las opciones válidas son visibles,
  • Problemas de formato/diseño: en páginas ASP.NET, tratar de diseñar controles de usuario independientes resulta ser una pesadilla ("Pero realmente queremos que todos los botones estén alineados verticalmente ! "en los controles de usuario independiente. Buena suerte con eso.)

lo consideraría páginas web con más de una funcionalidad sólo si el público objetivo está formado por expertos de dominio, es decir, personas que necesitan una gran cantidad de funcionalidad en una sola página para una mejor productividad (piense en el ingreso de datos o software financiero con muchas variables).

Incluso entonces, la mayoría de las veces, es posible separar páginas en unidades individuales.

0

Quizás debería preguntarle a las personas que usan su sitio. O mejor aún, solo observa a las personas usar tu sitio. Creo que eso le diría si su sitio está bien diseñado o si necesita cambiarlo.

Cuestiones relacionadas