0

I'm working on a browser-based DBMS application, and I'm running into some complications around the best way to handle user navigation while creating records.

Viewing and editing records seems pretty straightforward; I have three use cases (with one extension):

  1. View all records in an entity
  2. View one record in detail
  3. Edit one record, may include adding child records

Navigation through these is linear: the user views all the records, picks one, edits it (or doesn't), saves edits (or doesn't) and navigates back the way he came.

When creating a new record, navigation appears less straightforward. For this use case (extended by an optional "Add child records" use case) there are more navigation scenarios that seem reasonable:

  1. User cancels and goes back to what he was doing.
  2. User saves and goes back to what he was doing.
  3. User saves and creates another record of the same type.
  4. User saves and continues to the add child records extension.

(I've ruled out allowing adding of child records to an unsaved record, i.e. while still in the create context.)

Of these, I'm struggling with a UX issue for scenario 4. The essential issue is that the user is technically in the edit context once he saves the record, but functionally is continuing the creation of the record.

I see three possible options:

  1. Upon saving, send the user to the edit context for the saved record (use case 3).
  2. Upon saving, send the user to the view context for the saved record. Move the add child records extension use case from edit to view (use case 3 to use case 2).
  3. Upon saving, give the user the option of adding child records, and if so, go to a specific implementation of the use case.

Option 1 has drawbacks. If the user saves the new record and then goes to edit mode just to add child records, he also will have to save the parent record or cancel, which is poor design. So, not my favorite.

Option 2 is the one I'm leaning towards. I would change the edit context to just editing the parent record, rather than also being the place to add child records. This would also require repurposing the view context, since editing isn't viewing. Perhaps the current view context might be a "Grand Central" for a given record, from which you could do any sort of editing of that record.

Option 3 is another possibility, which would require more development work and might become a more complex way to handle the need than option 2. Not sure if I want to go that way.

So. How can I best accomplish this in a consistent and intuitive manner? Please share ideas and questions, and thanks for reading.

1

If you want to know the best solution from a user experience perspective, create mock-ups of a couple of those options and test them with a few people (you can use simple mock-ups to test design ideas) - you don't need to test with many people, and you will soon see which option one works best.

I only say this because I work with Enterprise software and it is the only way to work out which design works best for the people who will be using this solution day in/day out. You certainly don't want to piss them off by providing a solution which does not work effectively or efficiently.

The other advice I would give you is to keep things simple to start with (KISS principle). Get the core part of your solution working perfectly first, then you can always add further features later in your roadmap if they are truly needed. If you try to do all those use cases you might end up running out of time an compromising the core part.

  • Thanks for your response. In this particular case I have the luxury of developing for my own startup, so the only one I have to avoid "pissing off" is myself. Well, my wife too (the SME in this case). So yeah, I do want to avoid getting that I'm sorry honey but you're just going to have to tear it all down and start over look. :) Now, I'm working on being able to add child records to a record. Some of the entities are part of core requirements, such as adding parts to a distributor and/or vice versa. ... – BobRodes Jul 4 '16 at 9:59
  • So I need to resolve this before I move forward. I do have a couple of business types I can show it to, and I should do that. Thanks for the reminder. – BobRodes Jul 4 '16 at 10:00
  • Thanks for that additional context. Yeah - getting quick feedback from anyone will help you validate you are heading in the right direction (this can be business types or your friends & neighbours). If it helps you, I will say option three is the best of the three – SteveD Jul 4 '16 at 10:06
  • The thing I don't like about option 3 is that it introduces another step ("Add child records? Y/N") to the process when the user doesn't want to add them. Viewing the record just added, along with, say, an "Add child record" button, has the same number of steps for someone who does and removes a step from someone who doesn't. – BobRodes Jul 4 '16 at 17:14
0

I would say your option 3 is better. In option 2 you are again pushing user to edit same record which is frustrating and bad UX for user.

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.