This is a one or two part recommendation based on the solution that would be implemented to solve.
More information and conversation on my post in Nightly Bug reports.
Filter functionality as it stands is designed to be static until removed from the user. Filters look to be set up specifically for new and custom views that are designed to be static. This interferes with the All view unintentionally and would affect user flow and understanding of their data in AnyType. Additionally, it is not visually known (easy to identify) when filters are applied outside of the default All filter. This should be changed to support a better UI, user interaction and understanding of their data.
Search functionality is currently not present in the set view in a normal user expected way. Users would expect to see a search box they can type in and update the results in that way. This could help with the Filter issue above but potentially at the expense of performance. I.E searching all of the contents in the object and relations, tags, etc. on that object. If the search function is robust, it may remove the need for the filter request as the search function would be sufficient.
Sets, Collections, or any database view starts off with an All view. This view should be updated to clear/revert to the default filters for the All view on exit of the Set or Application.
If the filter function would not be considered/implemented in any way, a simple Filter UI change would do the trick and make things easier and more noticeable. A button. Have the button change style/colors when an addition outside of the default All filter for the type or collection is present. Change back after a click of the button that would clear the filter to the defaults and normalize the button back to its original default form indicating no additional filters present.
A simple search field that would temporarily search for any aspect of the data in the overall set and its objects. @sambouwer made a really neat suggestion by changing the scope of the search box and how it searches with a keyboard combo or something similar. If this was implemented, it may remove the need for a filter adjustment.
Related Posts and Issues
- You create a set. Inside of the set, you are looking for specific content inside of the individual objects in the set view. The content is in the body of (in this case) a Page. Let’s say you are building a wiki with multiple pages and data points. Finding the content written directly in the pages would not be possible from my understanding without an updated filter or search that extended into all details of the objects.
- As you build numerous sets and go to back to reference data in them, you would most likely go to the All section to find the content. Filtering will help you find the data you want and drill down into exactly what you want to return. Coming back maybe months later, you would likely forget you had filters applied. An automatic reversion of filter to default on exit or a button that is a set color or style would let the user know “I’m not seeing everything I thought I had in here. Oh, the filter button is blue instead of white! Let me click to clear my filters I left when I was in here last.”. Something visually noticeable to help a user know something was drilled into and to clear as data becomes a big deal.
Relations would not work because of the inability to set a relation mid document
Creating your own Type may work but would not appeal to the database heavy users
Additionally, sometimes a database/table view is best at finding key sets of data within (either visible or not) the set view. Having a way to scope into or out of the normal visible view of objects would be ideal and offer a much better user experience that is both familiar and robust.
As it stands, the filter works great for new/custom views within sets, collections, and other database views. This is not the case in the default ‘All’ view of each set due to the sticky static nature of the filter on exit. Improving the ‘All’ view with a prominent button or any user-friendly interface element will enhance the user experience, making the filtration process easier and more natural, as well as providing an essential feature for this Filter process. Especially as data gets populated and users move more toward a quick query instead of a temporary custom view for just this one purpose.
For the search feature, the ability to search would be great and intuitive for a user. Quick queries to find your data in a flash would be great. More so using the recommendations of others here such as the scoping search change with a keyboard shortcut or UI adjustment would be nice. Ex. User wants to find a page that has the phrase Period of Performance, or Effective Date within a page body. The search box may not be able to find this within a basic scope. So switching to an advanced or detailed scope would offer the ability to look deeper into the objects in your search query.
I hope this is not too long or confusing. Maybe the people involved in the conversation on my nightly post could chime in on this conversation to help make things more clear. My goal in this post was to explain in as much detail as I could and reference other potential hit points and documentation of these features. A filter feature that may be a great idea and original, and a search feature that may or may not do the same thing as the filter feature.