2

I have the following relations between the entities:

  • a user can have multiple projects
  • a user can have multiple scripts
  • a project can have multiple scripts

So, a script can belong to a user or belong to a project. My idea is to consider the script a separate entity regardless the "parent" entity (user or project). I have several questions

  1. Clicking the edit button (first mockup) will redirect the user to the script page (second mockup). Is it acceptable to "lose" the project header/context?

    • I could prepend the script name with the project title to give the user more context (Project Title > Script Name)
    • I don't know why, but I have a feeling that only the content below the tabs should change when I click the edit button but this will lead to unwanted behaviour. For example, if the user is editing a project script he will get two sets of tabs.
    • I could remove the tabs from the script page and have everything in a long list but the question still remains: is it acceptable to lose the project header/context?

  2. In the second mockup I have two buttons on the bottom of the page. Even if the tabs change (general, configuration, dependencies) the buttons will stay there. Those tabs are there just to avoid having too many fields one below the other. Will the user see this as a form with multiple sections? Users might think that the save button is only for the current tab.

My main issue is that the "script" is a primary entity (for the user) and a nested entity (for the project) at the same time. How would you improve the UX in this case?

project page script page

| improve this question | |
  • None of your questions seemed to address this concern - "My main issue is that the "script" is a primary entity (for the user) and a nested entity (for the project) at the same time". Am I misinterpreting something? – Andre Dickson Oct 28 '16 at 20:48
  • Editing a script that belongs to a user should clearly be done in a new page. Editing a script that belongs to a project seems trickier since I have more nesting in this situation. First one is user > script, second one is user > project > script. Is if ok if I use the same edit page in both cases? – Andrei Oct 28 '16 at 21:51
  • 1
    @Andrei "Is [it] ok if I use the same edit page in both cases?" I prefer it, in fact I expect I'd be disconcerting if there were two forms for the same process. – bloodyKnuckles Nov 27 '16 at 21:57
  • May be you can provide with an overlay? If it works out – NB4 Jul 26 '17 at 5:47
1

Regarding question #2:

What to do with Cancel/Save buttons when form fields are split between tabs.

As it is it appears the Cancel/Save buttons go with each tab, therefore I expect people will be clicking "Save" multiple times, once for each Script tab.

To clarify the relationship of buttons to the entire form, separate the buttons from the tab body by moving them outside the tab boundaries. A couple options:

1) Below the tab boundaries:

buttons below form

2) Beside the tabs and above the tab boundaries:

buttons above form

| improve this answer | |
  • 1
    It might be useful to make the label "Save All" to indicate that clicking the button will save data entered on all tabs, and not just the current tab. – Dwev Jan 22 '18 at 10:04
0

I could prepend the script name with the project title to give the user more context (Project Title > Script Name)

I think what you are going for is what is called a breadcrumb. The breadcrumb will signal location to the user while also allowing them to navigate, so I think it's a good idea to include it.

I don't know why, but I have a feeling that only the content below the tabs should change when I click the edit button but this will lead to unwanted behaviour.

The two sets of tabs can be confusing, especially if you are trying to use breadcrumbs. Either use a modal for the script entity or take the user to a new page.

Will the user see this as a form with multiple sections? Users might think that the save button is only for the current tab.

They probably would think that. If that's not what you're going for consider adding additional buttons, relabeling your buttons or using a pattern other than tabs.

| improve this answer | |
  • Let's ignore the tabs from the script form to keep is simple - imagine it is a long flat form. For server editing I use a modal. For script editing I need more space - so I'll use a new page. My question is if the script editing page should preserve the header of the project? – Andrei Oct 28 '16 at 21:48
  • You should use a breadcrumb at most. Keeping the project header as is will be confusing. – Andre Dickson Oct 28 '16 at 21:55
  • Github does it and it doesn't seem confusing. Take github.com/apple/swift. If you click on "branches" or "releases" you will still be in the "code" tab, keeping the repository header. They even add a 3rd navigation on those pages. What do you think about this example? – Andrei Oct 29 '16 at 8:15
  • @Andrei I don't think what Github does and what you are proposing are similar. You can do a mockup of the script entity nested in the project entity to make it easier for us to offer critique. – Andre Dickson Oct 29 '16 at 11:28
  • I realise that splitting the form into tabs is a different problem, so, to keep is simple, let's have a single long form. With that in mind, wouldn't it make sense to have the form inside the "scripts" tab of the project? – Andrei Oct 29 '16 at 13:16

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.