Are multiple entry points good or bad?

Question

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 1

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.

Answer 2

In terms of Information architecture faceted navigation is a legitimate approach to getting a user to the task or page they desire.

You're optimising site structure to fit the user's mental model.

• Ensure that the call to actions are clear.
• Ensure a consistent naming convention for the call to actions. This is important for to ensure you minimise frustration and to improve accessibility. I.e. If you have "Add product" make sure all "Add product" actions go to the same page.

Another quick note, if you gather information from the environment (such as the supplier name) from a different entry point use that information to pre-populate the form.

HTH

Matt

Answer 3

Typically, multiple entry points can lead to confusion among the users. If they see multiple ways that can potentially take them to the same action, they may be unclear as to what differences there might be between the two actions.

That said, however, the answer really is that it depends. Every situation has its own little quirks that you need to deal with. If you have two distinct user bases, with two different business flows, it makes perfect sense to have two different ways to get to the same place.

Answer 4

i'd let only the first two, they seem logical in a product <-> supplier relationship, the third looks complicated and kind of redundant to the second.

• later you can test and see which one of those people use (it will be only one) and remove the other.

Answer 5

I always provide multiple ways of achieving a goal. However, I have a structure to it. You shouldn't confuse the user as to what the thing is or use different terminology.

Blog post about it.

Here is what will happen.

1. Users will guess how to do something
2. If you provide multiple entries, they will guess one of those and be right. WIN. They will then keep doing it that way.
3. Alternatively, if provide one way of doing things, they will guess wrong, get frustrated, muddle, muddle, muddle, finally figure it out and keep doing it that way. LOSE.

In my experience, this is a definite and 100% yes. It does not confuse the user if you maintain the language consistency.

Answer 6

interesting topic

it has been common that certain destinations can be reached via >1 paths. An example: a user needs to find information about an activity (say golf) at a location (say perth).

In this example the user can arrive here either by:

1)navigating to a location then selecting an activity 2)navigating to an activity then selecting a location

Both scenarios are equally likely so you can't not design your information architecture around it. The problem with this type of user behaviour is that bredcrumb trails fall apart and wont work unless you add another dimension...but that's another story...