Smart Collections
Hopefully, this makes it clearer—@Shampra. At present, we haven’t decided which path is the right one to take, is it one or all of them? Feedback here is especially welcome, naming is not set whatsoever. To explain the differences:
- Traditional Query: all objects are constantly aggregated based on a ‘rule’ to form the view. Only objects that match the ‘rule’ are in the collection, which applies to past and future objects. No manual curation. This is the same as queries today.
- Collect Once: this is a collection like normal, objects that form the view have been decided by the user manually. The
collect oncefunction allows you to query the space for objects that match a ‘rule’, and then add them to the collection. If a new object is created that matches the 'rule’, this will not be automatically added to the collection because thecollect oncefunction is a one-off event trigger. You can trigger it again the future manually. - Auto Collect: this is a mixture between query and collect once. You can manually add objects into a collection and you can create a ‘rule’ to add objects into the collection, which would continue add/remove objects automatically based on the rule (just like a query). Therefore, you can have manually-added and query-added objects in a collection.
Our challenge is the mental model confusion. Traditional Query is clear, all objects are automatically aggregated based on a rule. Collect Once is clear, all objects are manually added by you. Auto Collect is fuzzy, some objects are added by you while others are added by the system. We are questioning if this is a good idea at all.
Nested Collections
A deeper explainer is here in comment #42—@Regis. In short, Online Shop is the parent collection, and Products is the child collection—together they are what we’re calling a ‘nested collection’. The properties in a parent collection are extended into a child collection. The purpose of this is to give more organisational depth, instead of all collections existing on the same plane. This is still an object-based system, however there are similarities to folders that can be simulated with this. You can imagine:
Clientsas the parent, withCompany A,Company B, andCompany Cas the child collections.- ‘Priority’ property in the
Clientsis used across all nested collections, but eachCompanycan have their own unique properties that the other nested collections don’t share. - This system can be used for tasks, projects, experiments, wikis, etc.
Nesting depth limit is not yet set as there are edge case complexities—@pomp. For example, can you branch nested collections? Can an object be in two different branches? If so, how to represent it in the UI? Additionally, deep nesting depth and long collection names create responsive design issues. If we foresee that many nested depths is a highly requested, then we can put more efforts into this.
- More property layout options: this is relatively easy to implement in the future, however we’ll stick with the main two in the beginning. As mentioned elsewhere, you can still add properties as blocks.
- Viewing all properties from all collections at once is technically possible, it’s unclear how much this would be beneficial. We want to keep the system simple and haven’t put much energy into this yet.
- All objects are automatically in the ‘Base’ (name not confirmed) if there is no user action. You could change the default of ‘create’ to a different collection, but we feel like the Base would function much better than the current default of ‘Page’ type.
- Clicking a ‘tag’ to open up a smart collection is a valuable idea, however it adds another parallel dimension to the organisation system. Multiple collections on an object performs a similar function to this. We will revisit this deeply after the first implementation of Collections 2.0 to get more community feedback to understand how helpful this feature would be.
- Collection management is indeed another big part of the new update. We did not want to overwhelm with the first prototype, but we can share more in the future.