Open DamianEdwards opened 12 months ago
a top-level "filter" UX that is a free-form text field that seems to only actually filter the name column
It is non-obvious until you do a matching search, but what the filter applies to differs from page to page, and is usually (though not always) more than just the name. On Projects it is Name and Source Location. On Containers it is Name and Container Image. On Executables it is Name, Path, Working Directory and Arguments. On StructuredLogs it is just Message and on Traces it is just Name. We actually highlight a couple of fields (e.g. Container ID) via that filter text that we don't actually filter to (looks like it was an oversight when the fields were added).
similar to the Excel column filtering UX
The grid has some support for this concept built-in, see e.g. this from the Typical usage example:
but it does not, to my knowledge, support any automatic filtering options (e.g. a checkbox list of all options, dropdown of all options, etc like Excel). We'd need to implement that ourselves.
Structured logs has a multi-field filtering capability - but the UI needs some cleanup - for example the record details page should have an option next to each field to use that value as a filter for other records.
Prioritize consistency here. New feature needs will be booted to post-GA
@kvenkatrajan @leslierichardson95 Are we still doing this?
@adamint did some changes for filters for structured log view in : https://github.com/dotnet/aspire/pull/2161 for preview 4.
I dont believe any additional work is planned for GA - @leslierichardson95 thoughts/desires :) ?
It is non-obvious until you do a matching search, but what the filter applies to differs from page to page, and is usually (though not always) more than just the name. On Projects it is Name and Source Location. On Containers it is Name and Container Image
@kvenkatrajan @leslierichardson95 This may want to be considered - allowing the filter search box to actually filter the values of all columns in all pages
Thanks @adamint . Since we have combined the resources view (container, project and executable) are we looking at the resource view for this scope or expanding it to additional views as well (structured logs is covered at the moment)?
I would expand it to other views too so that the filter input has consistent behavior everywhere, but if we need to prioritize I would suggest starting first with the resource view
I think we should prioritize this experience for the Resources page first and then expand to other pages in a future version.
Thanks - gone ahead and created : #2571 for tracking resources page filtering. Will move this ticket to post GA
Many views of the dashboard display details where it would be beneficial to sort and/or filter by specific values for various columns/fields of data. Today, these views have a top-level "filter" UX that is a free-form text field that seems to only actually filter the name column. We should consider standardizing on a UX that allows filtering views by any column based on the current values in the source (one/many/not) or by free-form text (similar to the Excel column filtering UX) or the Application Insights UX). Then the top-level free-form text box search could actually apply across all columns/fields, allowing for simple searching of things like a port number or image name, without having to specifically find that UX in the column-specific filters.
This multi-level experience would make it much easier for the user to quickly customize the view of data being presented to better suit various scenarios.