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):
- View all records in an entity
- View one record in detail
- 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:
- User cancels and goes back to what he was doing.
- User saves and goes back to what he was doing.
- User saves and creates another record of the same type.
- 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:
- Upon saving, send the user to the edit context for the saved record (use case 3).
- 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).
- 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.