4

Let's say I have a list of Drivers and a list of Buses. Now in my interface I am able to create an instance of a Driver and an instance of a Bus. Like below:

enter image description here

However as you can see, they can reference from each other as in a Bus can have a Driver and a Driver can have a Bus.

The dilemma is that they can be pre-requisites of each other, depending on which form you fill-out first. How do I solve this dilemma so that I can create an instance of a Driver and an instance of a Bus without them having the need to reference from each other? And when I need to reference/link them, how will that 'linking' interface look like?

Do I "Assign Bus" under Driver? Or do I "Assign Driver" under Bus? Or there's no right or wrong of the two ways?

Same issue for any many-to-many relationships types.. E.g. If you have a Movie CMS, do you "Add Actors" under a Movie or do you "Add Movies" under an Actor? Or a Library CMS, do you "Add Author" under a Book or do you "Add Book" under an Author?

  • Is it required to have for a Bus to have a driver at the time of creation? Or can you also create buses for which no driver has been assigned yet? – Mike M Oct 10 '17 at 13:55
  • @MikeM Not required.. Yes I can create a list of drivers without buses, I can a create a list of buses without drivers (means the last input field in the example above, I can remove that first). But my dilemma now is how do I create an interface to link the two of them? Do I "Add Buses" under a Driver.. or do I "Add Drivers" under a Bus? Or do I allow for both? Will it be confusing for users if both? Like if I wanna link a Bus to Driver, do I go to Bus profile or to Driver profile? – catandmouse Oct 11 '17 at 3:36
  • 3
    This seems to be dependant on workflow - What workflow are your users expecting? Do they normally create a driver and then assign a bus or vice versa? You'll probably need to go and ask them. – Andrew Martin Oct 11 '17 at 9:53
7

You can use list and detail views to enable quick linking, and allow users to attach the related entity from a dialog.

Buses and Drivers exist outside of their assignment to each other. It seems like they are both attributes of a route, which has 1 or more buses and 1 or more drivers.

Do you have a higher level concept like a Route?

I don't know what your data model is, but it seems a 'Route' or some top level object will be able to give you a view of all buses and drivers that are connected, plus if you have buses and/or drivers out of commission you have a top level view.

Since at any time there can be a pool of buses without drivers, and vice versa, allow them to exist at the same level, and crosslink to each other. This is helpful especially if a bus route shares multiple drivers and the opposite, since you can display a table and a detail view which shows these relationships.

From a bus list, I can drill into the bus detail view, but if you allow driver links, and a menu to add a driver, i can pop up a dialog to select from a list of drivers.

If there is no driver I was expecting in the driver dialog, allow me to add a new one. Once I submit, I see the new driver added to the bus list. I can then click the link on the newly created driver to be taken to that drivers detail view, where it shows the related bus.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

8
+25

Imho would add a 'trip id' to have a central point of connection. So a future bound trip would not reference any driver or bus until an opportune time. But context is key here. Unless there is a very specific reason to highlight which driver or which bus, keep it simple stupid. Fill a form for a trip/event then update as new information is required.

It allows data flexibility:

  • each driver may use different bus' per trip (a bus could break down/have an accident on the freeway)

  • each bus may have multiple drivers along a trips path ex. quebec(driver a) to toronto(driver b) to new york

To reference your example..

  • Movie, then Cast (Actors), videos, pictures, famous quotes
  • Book, then Author/s
4

This is an interesting problem, but I think you could solve it with relative ease.

This solution assumes:

  • You have compartmentalized style code (front end) for both forms
  • You have compartmentalized submission code (backend) for both forms

To start, consider this mockup:

Step 1

Two main changes to your original mockup:

  • Replace the text field with a drop-down, which populates based on drivers loaded into the system. What happens if a user misspells a driver name?
  • Add an option to create a new driver

Next step:

Step 2

  • Allows the user to input new driver data in same step
  • Disable bus no. box, as it should be the same as new bus (or hide this field completely)
  • Reset button text to match two actions

Once this form is submitted, the submit actions for both bus and driver are called.


Other thoughts:

  • If specifying the bus/drive link isn't immediately required, it may be fine to allow the user to specify later. However, be careful in case that task is forgotten.
  • Why not combine these into one "create" form?
  • Great solution, and a no-brainer for the user. – tobiv Oct 18 '17 at 13:06
1

Unless they're strictly required and only one driver is possible at any instance, the flows aren't related, but they will go in parallel. Otherwise, you'll have a lot of issues down the road. Your movie CMS scenario is a perfect example: a movie has many actor, and an actor may be featured in many movies.

Another example of this, since you're going to work with databases is.... databases! You create a database and you create users. Then you assign users to databases. Change database with bus and user with driver and there you go.

Thus, the flow could be like this:

  • First, user creates drivers (or buses. It's the same, but drivers are more likely to be added, modified or deleted. Also, you'll see in next step it will be more convenient when adding buses for the first time).
  • Then, s/he creates buses. In this step, you can offer a drop-down or checkbox (depending on the amount of drivers) where the user will be able to assign a driver to this bus.
  • And that's it!

It will look something like this:

enter image description here

Note: it's recommended not to require a driver, user may leave it empty and fill this information at a later time.

0

Know how your users think and work

This kind of problem is a very common and it all comes down to knowing your users mental model. Do they think of buses with drivers or drivers for buses?

Ask them and you know the right path:

Path 1.
Create or edit a bus and assign a driver. Or when the driver is not in the system, show additional form fields for a new driver > Save the form

Path 2.
Create or edit a driver and assign him/her to a bus. Or when the bus is not in the system, show additional form fields for a new bus > Save the form

If the path that users choose depends on different situations, it is possible to provide in both paths but each from different starting points in the application. But showing both paths at the same time/starting-point will add a lot extra cognitive load and is not recommended.

-1

Maybe you could allow multiple drivers per bus and/or multiple buses per driver, which would allow having 0 of them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.