This improvement was done in the middle of 2021. I played the role of a UX/UI designer.

Search results format

Requirements and issues

• Users can find a street/region, a group, or an asset (streetlight, cabinet, etc) by typing its external ID, name, and internal ID. Users can also find an OLC (the node that allows the streetlight to connect to the internet), a segment controller, or a router by its hardware address.
• First, the search results were not well-defined for different objects. Then not all these properties were displayed for an object by default. The search results were not clear enough for users to find a specific object.

The goal

This goal is to specify some rules to display the relevant search results so that people can find what they want more efficiently.

The rules are applied mainly to the search box of the dashboard page, but they can be also applied to the search boxes or combo boxes where users would like to find a street/region, a group, or an asset, such as the combo box on the report page.

Display rules

Principles

• We always show the objects that contain the characters they type in the search suggestion list.
• An object can have 3 IDs, which are external ID, name, and internal ID. For OLC, segment controller, or router, IDs can be up to 4, including the hardware address, which is not a property that displays for an object by default.
• All the IDs follow a hierarchy by importance. External ID > name > internal ID > hardware address
• If by any chance the value of the external ID or the name equals the hard address or internal ID, also follow the rule of the hierarchy of importance and never display duplicate information. For example,
  • if the external ID = internal ID and users type the value, show it as ID 1, and show the name as ID 2, no ID 3 is displayed.
  • if the external ID = internal ID and users type the name, show the name as ID 1, and show the external ID as ID 2, no ID 3 is displayed.
• Below is how each object is displayed in the dropdown list.
  1. The main label always corresponds to what the user is typing.
  2. A search result always contains the main label (ID 1), plus up to 2 sub-labels (ID 2 and 3).
     • The sub-labels are the 2 most important identifiers of the object, once ID 1 has been excluded. They are displayed by the hierarchy of importance after ID 1 has been excluded.
     • There could be a maximum of 3 lines for each object, which could afford up to 3 IDs, including 1 main ID and 2 sub IDs. The 2nd and 3rd line is optional. 

• The hardware address is a bit special. It can’t be displayed with any IDs in the 2nd line, which means it is only displayed when
  • users type it so that it would be ID 1.
  • the asset has no external ID and name and users type the internal ID, the hardware address is going to be displayed on the 2nd line.
• The principles above can be applied to all the search fields or combo boxes that are used for users to search for a street/region, a group, or an asset. For instance, use the format for streetlights/cabinets when users search for a single asset on the report page.

Use cases

Scenario 1: A user searches for a streetlight by typing its name.

• Name matches what users type most so we show it as ID 1.
• The characters that match users’ input are highlighted in the dropdown list.
• Then the external ID and internal ID are displayed as ID 2 and ID 3 by importance.
• The object 2 in the dropdown list, the streetlight has no external ID, the internal ID becomes ID 2 automatically.

Scenario 2: A user searches for an OLC by typing its internal ID.

• Internal ID matches what users type most so we show it as ID 1.
• Then the external ID and the name are displayed as ID 2 and ID 3.
• When the OLC has no external ID, name becomes ID 2 automatically. The hardware address won’t be displayed as ID 3 in the meantime if it has it.
• When the OLC has no external ID or name, display the hardware address.
• When the OLC has no external ID, name, or hardware address, hide the second line.

Scenario 3: A user searches for an OLC by typing its hardware address.

• Hardware address matches what users type most so that we show it as ID 1.
• When the OLC has external ID, name, and internal ID, show external ID, name as ID 2 and ID 3
• When the value of the external ID = hardware address, see what user type as external ID due to the rule of the hierarchy of importance. Then show name as ID 2 and internal ID as ID 3.

Formats for all the categories

Region/streets/groups

• The difference in the search results between a region/street that has been created in the project and a region/street in the HERE map is that we show the street/region path that user created in the project as the top priority when values are the same.
• For instance, there is a street called South Shanxi Road.
  1. User searches it in the project before it has been created. It shows as “South Shanxi Road, Huangpu District, Shanghai, China” in the dropdown list. The path is provided by the HERE map.
  2. User searches it in the project after it has been created. It shows as “South Shanxi Road, Southwest, Shanghai” in the dropdown list. The path is also created by the user in the project.

Streetlights/cabinets

Components in the assets

• All the components that can’t be searched by hardware address follow the formats of luminaires.
• The OLCs, segment controllers, and routers that can be searched by their hardware address follow the formats of OLCs.

States of the search field or combo box

When the search field or the combo box is active but users haven’t typed anything yet, show the ID 1 of the 5 most recently-searched objects.

When users type the characters in the field, highlight the same characters in what users type and in the ID 1.

When there is nothing found in the search suggestion, show the indication “No results” in the dropdown list.

Shared queries

As part of the important improvements for search and query, we would like to enable the sharing feature for custom queries so that users can reuse the queries that others created, or duplicate them, and make some minor changes to fulfill their own needs.

Current implementation and requirements

In Interact City,

• all custom queries are private by default. Users can’t make them public or share them in any way.
• users can’t duplicate a query whether it is predefined or custom. No duplicate action is provided.
• users can’t see the criteria or do any actions to the predefined queries except running.

In CityTouch (the old version of Interact City),

• all custom queries are public. Depending on the roles you are assigned, users can view, edit, delete, and duplicate them.
• predefined queries can be duplicated, but can’t be edited or deleted.

The requirement is to allow users to make a custom query public. Once a custom query is public, it can be seen and used by all users in the project.

User scenarios

Supported:

• As a user, I can make a custom query public so that other users in the project can see and use it.
• As a user, I can duplicate any queries regardless it is predefined or custom so that I could make full use of the queries that have been created. 
• As a user, I can see the criteria of predefined queries, and duplicate them.

Out of scope:

• As a user, I can share a query with someone else personally.

Definition of ‘public’

When a query is made public (or ‘published’) all users in the project can see and run it. 

By contrast, a private query can only be seen by its creator/owner.  

Publishing a query

The user can access many queries which are all listed in a new menu called All bookmarks (final name). Note that the menu is decoupled from the Advanced button.

Steps

1. User clicks All queries to reveal the list of queries.
2. In this example, the query the user wants to publish is “New query 01”.
   • Note that before publishing a query, you first need to create it. And when you create a query, it is private by default. 
   • User clicks on the query’s 3-dot icon to open the actions menu.
   • User clicks Publish.
3. A confirmation dialog pops up, which explains and reminds the user what publishing means. Click Publish to confirm the action.
4. Snackbar shows up on the top right corner to communicate the result of the action. The All queries drop-down remains expanded.
5. After the query is successfully published, a new ‘team’ icon appears, next to the 3-dot icon, to indicate the query is now public. This is confirmed by a tooltip that appears on hovering on the ‘team’ icon.

Unpublishing a query

A user can decide at any time to stop publishing one of his/her queries. Unpublishing means reverting to private. When a query is public, the Publish action in the menu is replaced with Unpublish.

Note that the user could achieve the same result by:

1. Duplicating the query (this creates a private copy)
2. Deleting the original query (other users therefore can’t see it anymore)
3. Renaming the private copy (assigning the same name as the original)

When user clicks Unpublish, a confirmation dialog appears, asking “Are you sure you want to unpublish the <query-name> query? You will still be able to use it, but other users won’t. ”

Viewing/editing a query

User can now inspect how a query works, i.e. what criteria govern it. When user selects View, the query creation UI appears, revealing the criteria of the query. The action is called View for queries that are read-only for the user (typically all queries created by others), but is called Edit when the user has the power to modify the query (typically all queries ‘created by me’). 

When the query is read-only, all its criteria are also made read-only.

Renaming a query

The Rename action is only available for queries that the user has created.

Naming constraints

• 2 queries in Created by me may have the same name as long as one is public and the other is private. Indeed the ‘team’ icon will allow the user to distinguish one from the other. See the illustration below.
• Queries Created by others must all have different names (indeed if two queries had the same name, we could not distinguish one from the other since they both have the public icon). 

Duplicating a query

The Duplicate action is available for any query. When a query is duplicated, the original is unchanged; the copy however is always made private and appears under the Created by me section. The copy has the same name as the original, but we append “copy” to it. 

Deleting a query

For a private query:

• Dialog title: Delete query
• Dialog body: Are you sure you want to delete the <query-name> query? 
• Buttons: Cancel, Delete

For a published query (and provided the user is the creator of that query):

• Dialog title: Delete query
• Dialog body: Are you sure you want to delete the <query-name> query?  This is a public query; if you delete it other users won’t be able to use it anymore.
• Buttons: Cancel, Unpublish and delete

Filtering queries

As user is entering text in the Filter field, the 3 sections are filtered out at the same time, hiding queries that do not match. The matching text portion is bolded.

Who can do what?

* Users who are grant the Query administration permission can maintain queries whose creator has left the project.  

More on the All queries menu 

Entry point

All queries is a dropdown that is independent of the project search field while the Advanced button is integrated to the search field. It directly opens the query creation UI.

List structure and behavior

Content:

• There are 3 sections, Recents, Created by me, Created by others, an input field to filter the queries within the list, and a New query button.
• Recents shows the latest 5 queries run by the user. Most recent at the top. A given query can at most appear once in that section, even if it was recently run multiple times. 
• Created by me and Created by others are alphabetically ordered.

Behavior:

• The height of the dropdown list depends on the height of the window. It always makes full use of the window height to display the information completely. The dropdown list is scrollable. When it is scrolling, the input field and New query button are fixed at the top and bottom. The minimum height of the dropdown is to display the input field, New query button, and at least one query item.
• Clicking New query button triggers the dialog of creating a new query, playing the same role as Advanced button in the dashboard search field.
• Dropdown list collapses only when:
  • user runs the query, either by clicking the list item or by save and run after editing.
  • user clicks somewhere outside the panel.
• Dropdown list persists open after:
  • user deletes, duplicates, renames, or publishes a query – so that user can see the result of their action

Empty state

Created by others should never be empty, because as a minimum it will show the Signify-predefined queries.