Completed

UI tabs component and menu

12 years ago • updated by 9 years ago • 6

Although the navigation has been improved with Back buttons and the Dynamic Sitemap (breadcrumbs), this is only navigation "backwards", there are still a number of problems going forward:

1. It is difficult to tell what buttons do
2. There is no standardized forward navigation process to related components and subsets of a component
3. Realestate is used poorly, and movement through the website requires a lot of scrolling

Solution:

To remedy this, the following is a suggested set of fixes:

1. Include a set of links (tabs) to the left of every page that define navigation within the component or context being viewed. (e.g. Connector details would have Schedules, Schema, Timings, General tabs etc.)
2. Each page would have a drop-down collection of operations for the component or context being viewed. (e.g. Connector details would have Add Schedule, Enable, Execute Full import etc. etc.)

Benefits:

This would achieve all of the listed problems above, but would also help with:

1. Standardization of display components, leading to reusable Web components which benefits every product and every plugin.
2. Standardization of navigation, to allow for components like the EB/IDB security to apply business logic to each context.
3. An entry point for plugins to add Navigation and Operations. (e.g. FIMEngine.dll adds a FIM tab to adapters)
4. Helps with localization by reducing the noise in views.

Ultimately the overall result would be that I would be able to say "Now run a Full Import" and it would be intuitive that it's in the drop down, as opposed to "Now scroll down to where it says Full Import, then find the table icon with the green refresh icon and click that"

image (2) (1).png
image (4).png

Vote

Replies 6
Oldest first
- Newest first
- Oldest first

12 years ago

Additionally, with regards to the attached screenshot, we could add links just under the horizontal rule to segregate out the components of that context. So for the operation list you might have:

Operations | Schedules | Statistics

which updates the content below, and also updates the section on the left.

Additionally, for tab-specific child operations, the links could be above the breadcrumbs, this might require the background to be lighter to allow for text to sit on-top of the background colour and still be readable.

12 years ago

[Tab("ConnectorDetailsTab")]
[Tab("ConnectorJobsTab)]
[DynamicValueMapping(...)]
public ActionResult Connector(Guid connectorId)
{
       return View("Connector");
}

[DynamicValueMapping(...)]
[TabContent("ConnectorDetails")]
public ActionResult ConnectorDetailsTab(Guid connectorId)
{
       return View("Connector", "ConnectorDetails");
}

[DynamicValueMapping(...)]
public ActionResult ConnectorDetails(Guid connectorId)
{
      return PartialView();
}

[DynamicValueMapping(...)]
[TabContent("ConnectorJobs")]
public ActionResult ConnectorJobsTab(Guid connectorId)
{
       return View("Connector", "ConnectorJobs");
}

public ActionResult ConnectorJobs(Guid connectorId)
{
       return PartialView();
}

A master page ("Connector") would define the Tabs that belong to it. When the "Connector" page is rendered it would request each tab based on these attributes.

Each tab itself would have both a View and PartialView action ("ConnectorJobsTab" and "ConnectorJobs"). The View action would return the view of the master page ("Connector"), with a token to notify that the particular tab had been selected; the correct partial view would then be loaded into the right-section based on the respective TabContent of the selected tab.

More importantly, as the tab content is separated, and an attribute-based direct link is made, the content could be loaded in when JS is enabled.

An extension method should be added to automate this.