This improvement was completed in June 2022. I played a role as the UX/UI designer.

Issues to be addressed

• Inconsistent menus on the map and in the panel. When users select some assets, they can do a bunch of actions either from the map or from the table in the panel. Before the improvements, the actions people could do from the map or from the table were not the same even if they selected the same group of assets. And there is no logical reason why it can be done in only one of the ways.
• The structure of the action menus is a bit messy. How the actions should be grouped, what are the frequently-used actions, how to organize the menu to make people feel convenient and efficient, how to call different actions in different types of assets, etc, all those questions haven’t been asked before. With more and more actions being added to the menu, we were in desperate need of a cleanup.
• Not well-defined behaviors. When an action should be disabled, when it should be completely hidden, what we should show when nothing is selected, what we should show when user clicks outside of the project-defined areas, what we should show when there is a mixed selection, how the menu should react when the size of the window changes or becomes limited, etc, we need a clear definition of all those questions.

Below is my solution.

Principles

Panel and map show the same menu

• The action menu can be opened either from the panel or from the map – and its contents are the same in both cases – except for a few actions that only make sense on the map, for example, Move to new location, Connect to segment controller, etc. Such actions indeed require the user to interact with the map to be completed.
• The menu’s contents are NOT influenced by view modes, data visualization, or panel layout.

Dynamic action bar

• Located at the top of the panel.
• Shows as many actions from the menu as possible, from left border to right.
• The topmost item in the menu is the leftmost item in the action bar.
• When space is not sufficient to show all actions, collapse the remaining ones in the 3-dot menu.
• The bar never shows disabled (greyed out) actions, so as not to clutter the bar real estate. Instead, when an action temporarily does not apply, it is removed from the bar.
• The 3-dot menu only shows actions that didn’t make it to the bar.
• The 3-dot menu only shows up when it has at least 1 action to show.
• Export and density controls are always shown on the right side of the bar.
• Menu items that lead to a submenu are represented in the bar as dropdowns.

Scrolling indication

• Show a visual indicator (bottom arrow) when the window height does not allow us to display a menu in full. User scrolls the menu by using either the mouse wheel or clicking the arrow area.

Dynamic position

• It always fits in the viewport.
• Show action menu completely when window size permits.
• The position of the action menu depends on where the click happens on the map, or where the button is on the panel action bar.

From the map

From the panel

Actions are contextual to the object type

• The type of the selected objects determines the set of actions. In the map, the user can only select assets, but in the panel, different kinds of objects can be listed and selected (faults, OLCs, assets, etc.).
• In general, an action is hidden from the menu when the user doesn’t have the required role to see it. The action is shown but disabled (greyed out) in the menu when the user is allowed to see it but can’t trigger it in the current context (for instance Apply manual override will only be enabled for commissioned assets that aren’t overridden already).

Mixed selection (disambiguation)

• When multiple different types of assets are selected, users have to choose one type of assets first before going to the specific action menu. This is as per the current implementation.

From the map

From the panel

Differences between map and panel menus

Specific to the panel (action bar)

• Actions that aren’t applicable in the current context OR for which the user doesn’t have the required role, are hidden.

Specific to the map

• Actions for which the user has the required role BUT that aren’t applicable in the current context, are visible but greyed out.
• Actions for which the user doesn’t have the required role are hidden.
• A specific menu is defined for when there are no assets selected (create actions).
• Move to new location
• Connect to segment controller
• Clone
• …and any other action for which a direct interaction with the map is needed

Platform sensitive

Desktop (pointer devices)

• On the map:
  • Right-click to open the menu
  • Hover on a submenu entry to open the submenu
• On the panel’s action bar:
  • Click the 3-dot icon to open the menu
  • Click on a submenu entry to open the submenu (consistent with dropdown behavior)

Mobile (touch hybrid devices)

• On the map:
  • Long press anywhere on the map to open the menu
  • Tap a submenu entry to open the submenu
• On the panel’s action bar:
  • Tap the 3-dot icon to open the menu
  • Tap a submenu entry to open the submenu

Examples

Menu structure

This section specifies the full set of actions for each asset type, as well as how they are organized in the new unified menu. Depending on your roles, on the control systems enabled for the project, etc. you may not see all those actions.

Use cases/prototype

Last part, I prepared 4 prototypes for 4 different use cases (cellular streetlights, RF streetlights, RF cabinets, and markers), and we let the users try the prototypes and gave us feedback. Below is one of the examples.

User case: cellular streetlight