gui design - Are multiple entry points good or bad?

My example is a web-based application, but I guess this could go for anything: Multiple entry points for the same action, good or bad?

My example:

Adding a product against a supplier (vendor).

This could potentially be done via:

• Product -> Click "Add Supplier Product" (then select the supplier)


• Supplier -> Click "Add Product" (then select the supplier)


• Supplier -> Select the supplier from Supplier List -> Click "View Suppliers Products" -> Click "Add Product"

All valid entry points, if we use only one, each have pros and cons that either enhance the experience or confuse the user. Is there anything wrong/confusing with having multiple entry points to the same action?

Answer

As a general usability principle, you want to provide openness and flexibility, allowing users to do whatever they want whenever they want. This argues for providing multiple entry points rather than forcing users to follow only a single possible path which they may not know or may have forgotten or may not be consistent with their way of thinking.

The concern is that multiple paths can mean more complex menus and information architecture that add clutter, get users lost, and otherwise potentially cause confusion. There are a few variables that can mitigate this.

Object-centered Structures

Firstly, as apps get more complex, with more possible tasks and paths, you can control both menu and architecture complexity by adopting an object-centered structure, rather than a wizard-like task-centered structure typical of web apps. In an object-centered structure, each page represents one or more object classes for which all tasks involving those classes can be accomplished. In a task-centered structure each page represents a single task or a single step in a task.

With an object-centered structure, you may have a Products page listing all products, with the supplier for each indicated in a field (which the user can sort on). Alternatively, you have a Suppliers page listing all suppliers, which includes the products for a given supplier in a tree or master-detail layout. Either way, all the information is on one page making the simplest menu and architecture and eliminating or at least reducing the need for multiple entry points.

Duplicating between Pages (versus in Pages)

Secondly, having duplicate commands on two different pages is not nearly as problematic as having duplicate commands in two different places on the same page. With the latter, users will wonder if the two commands are really the same or not. In contrast users often expect the same commands to appear on different pages (e.g., in side bar menu).

Depending on the tasks you need to support, it may be necessary to have both a Products and a Suppliers page even if you have an object-centered structure. However, having an Add Product menu item on both the Products and Suppliers pages is probably okay. Having an Add Product menu item under Product and Supplier menus is probably not.

Consistent Labels and Rules

Thirdly, multiple entry points result in the least complexity if they use the same labels and follow the same basic rules of interaction. For object-centered structures and most desktop GUIs, the basic rule is that if the user can see it, the user can interact with it. If users see products on both the Products and Suppliers page, they’ll expect to be able to interact with them, including adding to them. This is analogous to providing links to content whenever it is cited in a web site.

Consistent labels will help signal to users that it’s the same command in a different place, so be sure to consistently call it “Add Product,” not “Add Product” in one place and “Insert Product” in another.

Simple consistent rules can also simplify your menus. If your app supports object focus (necessary for master-detail relations), then you only need an Add menu item. If focus is on products (on either page) it adds a product. If focus is on the suppliers, it adds a supplier.