search

silverstripe / silverstripe-cms

Silverstripe CMS - this is a module for Silverstripe Framework rather than a standalone app. Use https://github.com/silverstripe/silverstripe-installer/ to set this up.
http://silverstripe.org/
BSD 3-Clause "New" or "Revised" License
515 stars 333 forks source link

New Search UI for Pages, ModelAdmin and GridField #1777

Closed clarkepaul closed 6 years ago

clarkepaul commented 7 years ago

Overview

Update the way in which search functionality can be accessed throughout the CMS. This might need to be separated out into different issues/tasks if it functions differently for each area.

Acceptance Criteria

Baseline

Simple Search

Advanced Search

GridField-specific

Notes

Older style of pages sections: image

Related

Subtasks

PRs

chillu commented 7 years ago

Note that I'm proposing to remove the ability to show page results in a tree view: https://github.com/silverstripe/silverstripe-cms/issues/1926

newleeland commented 6 years ago

Potential ModelAdmin design direction [Dev feedback required]

artboard copy Move search all the way to the right

artboard Search field takes precedence, and covers Tabs and even title when search.

artboard copy 2 Advance options fields will be dependent on the content of that section.

So the issue here is that ModelAdmin/Gridfields don't have a user-friendly primary/default type of data like Page name (in page) and filename (in files) for a one input field design to default to, as ModelAdmin/Gridfields search is by column. It would be good to have one input that searches multiple columns, With advance options limiting the scope of the search

newleeland commented 6 years ago

Issue1: Search mechanics changes

Another issue is the search mechanics vary between Page/Files and ModelAdmin/gridfields. The newer search has only one default field to search, this is good design (nngroup). This works well for areas like Pages/Files which have one primary search term – the NAME. Modeladmins/Gridfields don't have a primary search term to default too.

Solution

Hence, if we were to use the single input search in ModelAdmin/gridfields, it would be required to search across all columns.

Issue 2: Search hierarchy changes

Further research suggests that this search would not work for rest of CMS (with modelAdmins, grid fields) as modelAdmin search is currently right next to the tabs on the top bar (top level). This suggests everything across the tabs are search, however, this is not the case. The search only searches within the tab that is selected. screenshot-2017-11-16 silverstripe - test modeladmin

Solution

So there are 2 two alternative positions 1. Underneath the tabs instead of next to the tabs Positionally this works rather well, however, the visually it looks out of place for modeladmins wouldn't align with Files/Pages poc_pl_gridfield_search filters copy 3 poc_pl_gridfield_search filters copy 4 poc_pl_gridfield_search filters copy 5

2. inline with gridfield labels on the right side. (his direction has major UX issues) like search field needs to collapse after searching, in case the user needs to use the sort functionality. This means user needs click again search to research. poc_pl_gridfield_search filters copy 9 poc_pl_gridfield_search filters copy 6 poc_pl_gridfield_search filters copy 7

Combined solution

poc_pl_gridfield_search filters copy poc_pl_gridfield_search filters poc_pl_gridfield_search filters copy 2 poc_pl_gridfield_search filters copy 8

chillu commented 6 years ago

I think it's time for some acceptance criteria :D

clarkepaul commented 6 years ago

This issue has become ModelAdmin search or general purpose search—its supposed to be site tree search which becomes a list view search, so no tabs etc. as per designs provided here https://github.com/silverstripe/silverstripe-cms/issues/1891

@chillu do you want this to become a general purpose search issue? maybe we adjust the issue heading.

newleeland commented 6 years ago

ModelAdmin example poc_pl_gridfield_search filters copy

Pages example slice

chillu commented 6 years ago

@newleeland I like it :) My concern is that we're hiding away the "more search options" panel with a miniature triangle icon without a label. That's following on from the "assets" UI, but kind of assumes that most of the time you'd search with the single field instead of opening "advanced" options. That's a technical challenge, since not all database columns are configured to be "searchable" (don't have a full text index). Which might be a separate technical task to allow for a design like this to work by default. The triangle is right in the middle between "clear" and "close" icons, so it's going to be hard to aim for on mobile screens. Also what's the difference between "clear" and "close"?

You're also introducing a presumably editable search syntax here: Are authors expected to type out Type:Page Locations here, limiting to Page type, and doing a full text search on Locations? That implies that we can convert these text representations back and forth between form fields and the editable summary. Or would Type:Page be readonly, and only Locations editable?

In general, please add more reasoning for your designs on tickets, where you're introducing major new concepts like a custom search syntax.

clarkepaul commented 6 years ago

I should also add some of the discussions I've had with @newleeland.

newleeland commented 6 years ago

Updated POC design https://invis.io/NP79NDU4J#/267837241_POC_PL_Gridfield_Search_1

Advance options The little triangle pattern (advanced options) is quite common pattern for more options (google drive, gmail).

One main search input vs multiple There have been studies done, outlining that most users don't use advanced search features. Yes, After talking with @flamerohr, we could have "title" as a default (primary) set of searchable data, which users can search. The other options would require the search term be searched in all the columns, which is not very performant to my understanding.

Editable inline search syntax Again, talking to @flamerohr this would require extra work. In the new design, the filters that are applied are not editable, once clicked could open the advance filter drop down.

newleeland commented 6 years ago

Updated Designs

This searching pattern stems across 3 main areas Models, Pages and Files using a global search pattern and use the search results design in #1891. GridField uses a similar look although it doesn't navigate the user away as per designs below.

1. Global Search

Basic Search mechanic (ModelAdmin) WIP designs ~https://invis.io/FTG16IYV5KB#/284539432_POC_CMS_Search_Model_Start_C2~

Other Variations

Pages (collapsed tree variant) ~https://invis.io/FTG16IYV5KB#/284543655_POC_CMS_Search_Page_Start_C2~

Files advance search ~https://invis.io/FTG16IYV5KB#/284543652_POC_CMS_Search_Files_Advance_C2~

2. In-Context Search (gridfield only)

We decided not to use the layout which is used for Pages/Files/Models for Gridfields as they work better as a in-Context filter (one level), rather than a global (multi level). Hence, the search mechanics work a little differently. It is a better experience to keep the user in the same view to see the results. ~https://invis.io/FTG16IYV5KB#/283335176_POC_CMS_Search_Gridfield_Start_C2~

Note

See list of all Search flows ~https://invis.io/FTG16IYV5KB#/284539428_POC_CMS_Search_Menu_C2~

chillu commented 6 years ago

I have been communicated the scope of the search before searching (eg Search pages)

Renamed to "I can tell what I'm going to be searching for (e.g. "Search MyObject")"

I have a Search bar appear only when I require it, and can open/close the search bar when required

Renamed to "I can toggle a view with more advanced search inputs"

If multiple GridFields are in the same view I have the possibility to search these individual GridFields independent of the other GridFields

Simplified to "A view can have multiple searchable GridFields, and search controls are clearly associated with the related GridField"

browser help text to clarify "X" searchbar button with "Close and reset" when I hover over it for a long time. browser help text to clarify "▼" searchbar button with "Advanced" when I hover over it for a long time.

I've put that into notes, should be part of our DoD anyway

chillu commented 6 years ago

@newleeland Your ModelAdmin designs don't account for tabs. You pointed that out as an issue back in November. I assume that means we're keeping the search icon left of the tabs, as currently implemented?

clarkepaul commented 6 years ago

I think that the search icon is positioned in the top toolbar if there are no tabs (as per Pages and Files), and this was done to allow people to build ModelAdmins with a search functionality over an entire admin area if they have a single type of "thing" which could have a nested structure (@chillu not sure if this is actually needed though?), but if the search is only based on GridField data then it would be below the North Toolbar as per the GridField designs.

chillu commented 6 years ago

I think that the search icon is positioned in the top toolbar if there are no tabs (as per Pages and Files), and this was done to allow people to build ModelAdmins with a search functionality over an entire admin area if they have a single type of "thing" which could have a nested structure

Not entirely accurate. Files don't have toplevel tabs. Pages don't have toplevel tabs in the list view. In the tree/detail view, the toplevel tabs are visually separate from the search trigger. There is always toplevel tabs in ModelAdmin, even if you only manage a single model. It's technically not possible to search across multiple managed models through the same search UI or trigger.

but if the search is only based on GridField data then it would be below the North Toolbar as per the GridField designs.

Each of these sections can contain GridField in the edit forms which allow their own search, and those wouldn't live in the north toolbar. Technicall, all the lists shown around the CMS are "grid fields", so your statement is a bit confusing :)

@newleeland We need designs for how the search trigger interacts with tabs for ModelAdmin.

clarkepaul commented 6 years ago

There is always toplevel tabs in ModelAdmin, even if you only manage a single model. It's technically not possible to search across multiple managed models through the same search UI or trigger.

Thats what I'm trying to say, Pages and Files differs from most areas because you can search an entire hierarchy, I just wasn't sure about whether people could build a ModelAdmin with the same search modal as I'd never seen it before—your reply has clarified that point that you can't.

This differs from GridFields where you can only search a single level, so the search icon makes sense to be more attached to that area, especially if there are multiple Gridfields on a single view

And we're moving the Modal admin search icon from before the tabs to sit within the tab you need to search within as you can't search across multiple tabs.

chillu commented 6 years ago

Design notes for @newleeland:

image image